[lsb-discuss] Packaging

Leibowitz, Michael michael.leibowitz at intel.com
Mon Oct 23 22:36:01 PDT 2006

If I understand you correctly, for third-party packages, we should
create an API to manipulate them and leave it up to the distros to
implement it?  I'm all for having API's for programmatic manipulation,
but creating a full set of API's is just a package manager that is
driven by API instead of user interaction.  Although we could just
specify the API and not give an implementation, my experience has been
that API's that were standardized without a reference implementation are

Michael Leibowitz
Software Engineer, Channel Platform Solutions Group
Intel Corporation
michael.leibowitz at intel.com
+1 503 264 7621

>-----Original Message-----
>From: lsb-discuss-bounces at lists.freestandards.org [mailto:lsb-discuss-
>bounces at lists.freestandards.org] On Behalf Of Chris Lee
>Sent: Monday, October 23, 2006 4:29 AM
>To: lsb-discuss at lists.freestandards.org
>Subject: Re: [lsb-discuss] Packaging
>Jiri Dluhos wrote:
>> On Saturday 21 October 2006 21:47, Alexey Eremenko spoke thusly:
>>> hi all !
>>> before I begin lets learn two terms: -first package manager
>>> (=distro-specific-PM) (=base PM) -second package manager (=LSB-PM)
>>> I thought about package managers recently.
>>> I think that by converting packages (from second to first, like
>>> alien), it would be hard to achieve good stability.
>>> I came to conclusion that second package manager must exist, with
>>> only few mandatory packages installed already, those are:
>>> 1. LSB 2. LSB-Desktop
>> Hi all :-)
>> Well, call me narrow-minded traditionalist if you want :-) but I
>> think having two package managers is a way to Hell. One such beast is
>> more than enough. Imagine all problems a package manager has to
>> solve:
>> * presenting packages to the user in a concise and understandable
>> structure * a fast and effective search in packages * effective
>> storage of package metadata, allowing for fast searches * secure and
>> reliable online updating system * atomic installation/deinstallation
>> process with safe fallbacks
>> Now multiply all this by two, plus significantly more trouble coming
>> from interactions from these two. That would open a new dimension of
>> horror.
>> (Note that I know what I'm talking about - we have much fun with our
>> package installer here in Novell. Having two of them, our packagers
>> team would probably commit suicide right now.)
>> Best regards,
>> Jiri Dluhos
>I have to agree, as it is they are a pain to use, even in GUI format, I
>still don't know what's going on in the Ubuntu synaptics goody.
>If we have:
>a) one LSB package type
>b) a defined set of LSB package manipulation interfaces
>c) a defined result of the executions of those interfaces
>Then we can leave it up to the distros that don't use the LSB packages
>as standard to create whatever wrapper they want to integrate LSB
>packages into their system so long as the defined interfaces and
>are followed.
>If the LSB package interfaces are good and full featured including
>things like repository interaction then distros may start to find
>keeping two systems is not worth it and migrate to LSB packages only.
>And while we are about it can we try and re-label these
>monsters "software package managers", as most newbs don't have a clue
>what a package is and why you would want to manage it.
>lsb-discuss mailing list
>lsb-discuss at lists.freestandards.org

More information about the lsb-discuss mailing list