[packaging] Comment #20: re LSB 4.0 Core beta specification

Peter Dolding oiaohm at gmail.com
Tue Dec 30 19:23:58 PST 2008


On Tue, Dec 30, 2008 at 11:25 PM, Jeff Johnson <n3npq at mac.com> wrote:

>
> On Dec 30, 2008, at 3:39 AM, Peter Dolding wrote:
>
>
>
> On Mon, Dec 29, 2008 at 11:12 AM, Jeff Johnson <n3npq at mac.com> wrote:
>
>> The LSB packaging standard needs to attempt a semantic model for
>> the interpretation of packaging format and content.
>>
>> The original issues (iirc) blocking a specification
>> of the semantic interpretation model had to do with
>> erase-before-install versus install-before-erase.
>>
>> That issue is not very hard to address in a specification.
>>
>> Already the install and erase (but not the upgrade)
>> model for dpkg and rpm are largely identical (at least
>> formally) identical. Details will matter, likely
>> hooking and extensibility and configuration and ..
>> the details __ALWAYS__ matter.
>>
>> But its obvious from symmetry principles that
>> there are not a large number of "upgrade"
>> models that need to be specified.
>>
>> Without a semantic interpretation model, a specification
>> for, say, "Table 22-14. Package Dependency Attributes"
>> is largely irreleavent. Sure there are bits, and sometimes
>> they are on (or pff). But the meaning of the bits can
>> only be specified wrto a semantic interpretation model.
>>
>> I also suggest looking quite carefully at Mancoosi (nee EDOS)
>> package models. They have quite easily succeeded avoided
>> "packaging wars" with a model that accomodates two formats
>> with multiple depsolvers, unlike LSB.
>>
>
>
> Not a bad framework.   Mancoosi is design from an admin point of view.   It
> will be interesting to see it in time when they get code doing there
> interface how it compares upto freeipa.org.
>
>
> You ought to read Mancoosi goals before claiming "admin" POV. Unlike LSB
> packaging,
> Mancoosi does have less lofty and more specific goals, more in line with
> distributing software.
>
>  I suppose that qualifies as an "admin" point of view.
>

Yes I did read the goals.   Yes they are Admin style.  Not ISV style.
Admin style controlling network from centrel server.   ISV style provide a
repository where admins can select to install applications from or not
install applications from.

ISV and Admin has very related objectives when it comes to installing and
uninstalling cleanly.

>
> And you need to look harder, there are most definitely tools brought
> forward from EDOS,
> used/contributed by both Mandriva and Caixa Magica.
>
> Why not compare freeipa.org and Mancoosi yourself?
>

Freeipa.org is also reworking sections of theres policy management that
overlaps with package manager.   It even might end up that mancoosi and
freeipa might be mergable.

Basically not quite the right time to compare them.  I will when the time
for both projects is right.   Main reason for waiting for it coded before
compared some cases design has to be altered.

>
> Of course with some alterations Mancoosi might be alterable to suit
> ISV's.   http://www.mancoosi.org
>
>
> I'm never sure I've met an ISV. I'll ask if Mancoosi is suitable on next
> meet-up.
>
> It would be interesting to get feedback from others.   Mancoosi is still
> design with the idea about not giving a stuff about the distribution under
> but it includes the option of including distribution dependant parts were
> needed.
>
> And I suppose LSB's "The Berlin API" is a fully fledged release rather than
> a "design"?
>
> Prototype code to The Berlin API already exists.  So yes you can play with
it and see how it works.  Now remember Berlin code name is straw man.  For
the simple reason its the bare minimal solution.   Not the best solution
that could be design.  Its basically the bare min all designs should be
trying to be better than.

Code is ready for a fully fledged release.  Just not at this time.   More
worry about other problems that hopefully have better solutions before the
failed location of Berlin has to beused.

Yes The Berlin API is designed with the idea of package scripts/installer
never been run with privilage.  So not exactly a state machine.   User
without rights to do anything perminate runs them.   Only way to do a long
term alteration is talk to the Berlin API that is logged.

Same logic we know package scripts can be dangously buggy.   Logging of what
package script does can make the operational rollbackable.

Yes Berlin is designed to address many issues.   Just does not do everything
nice.   Lot of time has gone into Berlin.

Peter Dolding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/packaging/attachments/20081231/9c03c55c/attachment.htm 


More information about the packaging mailing list