On Mon, 2008-06-23 at 00:08 +0200, devzero2000 wrote: > > > > On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes > <hughsient@xxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
