LSB Package API

[Denis Washington]

On Mon, 2008-06-23 at 00:08 +0200, devzero2000 wrote:
> 
> 
>         
>         On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes
>         <hughsient at gmail.com> wrote:
>                 On Sun, 2008-06-22 at 20:02 +0200, Denis Washington
>                 wrote:
>                 > The distro model is nice (and arguably better than
>                 the LSB Package API)
>                 > if the packages you like to have are in the repos in
>                 sufficiently new
>                 > versions. But if you need to go past that (bleeding
>                 edge versions, not
>                 > widely spread apps), things get more difficult
>                 currently. Especially
>                 > propietary applications just cannot be distributed
>                 by the distros
>                 > directly.
>                 
>                 
>                 Right. These packages are compiled against system
>                 versions of libraries.
>                 Do we choose the F9 or rawhide version of xulrunner to
>                 link against?
>                 There's substantial API and ABI changes between distro
>                 versions for the
>                 majority of shared libraries.
>                 
>                 > I don't think this is a corner case at all. For one
>                 thing, propietary
>                 > applications might just don't play a role _because_
>                 there is no really
>                 > good distribution method for them - the typical
>                 chicken-and-egg problem.
>                 
>                 
>                 Incorrect. Most closed-source applications I have to
>                 use are installed
>                 with an installer binary or script, which just
>                 smatters files on the
>                 hard drive in /opt. There's just no need to register
>                 these with the
>                 native system package manager as there are no updates
>                 repositories nor
>                 dependency tracking required.> 

Well, if there is no update tracking, there is naturally no gain in
having the application registered with the package (well, perhaps except
the user being able to uninstall the application with their package
manager and ISVs not having to provide an explicit uninstaller). But a
way of tracking updates _is_ planned, even if it isn't in the spec right
now. This is especially crucial because LSB applications may not depend
on anything else but the LSB itself, that is, they need to care a lot of
libraries around. Without update integration, this would certainly suck.
But it should be possible in a "final" LSB Package API by all means.

>         You you like an opinion on this, well, that it is mine. For
>         example, look ad Oracle Client 11g
>         application : it. as released with a tarball or so, have on
>         it:
>         
>         - a full stack of perl 
>         - a full stack of shared library : glibc in primisis.

Wow, that's taking it to the extreme. Both glibc and perl are in the LSB
afaik.

>         So what have to do un poor packager manager with this ?
>         Disable the deps and hope the best. Other, as MQ client, are
>         released with RPM : with deps disabled anyway. But not all
>         are equal : for example websphere. Sure it is tricky to
>         package it but almost don't force me to disable the deps: I
>         DON'T WANT DISABLE THE DEPS.

Well, the problem with arbitrary dependencies is that you can't
guarantee that every distro has them, or has them in the correct
version. But as the many important libraries are in the LSB and thus are
used system-wide, the problem of having to package the remaing ones with
the application is not that big IMHO, especially if there is integration
in the packaging system's update tracking.

>         IMHO, YMMV as usual

Sure, same for my reply naturally.

Regards,
Denis