On Mon, 2008-06-23 at 00:08 +0200, devzero2000 wrote:
On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes
<hughsient(a)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