[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: LSB Package API

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.

> Second, this way of distribution will help open-source projects as well.
> It would make it really easy for them to distribute bleeding-edge
> versions of there apps that integrate well into the packaging system
> without having to package for each and every package manager.

Who supports these bleeding edge packages? Where do the users get
security updates from? What if the library it's compiled against also
changes to a bleeding edge version too? This is not a standard use case,
unless you want a system like gentoo where you compile from source.

> It will
> also help those projects which are not widely used enough to be in
> distro repos, as they can more easily release binary distributions
> without having to depend on getting packaged by the distros.

Bad argument - see the PackageKit archives for details why this is a
really, really, bad idea.

> I really
> believe this decentralism would be very nice to have, especially in
> something as naturally decentralized as the open source community.

Err, open source communities are not decentralised. They are _more_
centralised than closed source software. I currently use one vendor for
my new software, my updates and also all the metadata and translations.
I use the same vendor for talking to users on forums and developers on
mailing lists and use the same channel for pastebin and collaborative
editing. My vendor is Fedora.

Calling an open source community decentralised is a very naive statement
in my honest opinion.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]