Re: OT: Saving GNU/Linux FOSS in the age of Android and iOS
On Friday 04 November 2011 14:25:03 Bill Cox wrote:
> Sorry for this off topic post, but I think this list reaches many of
> the people in Debian community who combined have some influence over
> the direction of Debian. If there is a better forum for this
> discussion, please let me know.
Sorry for responding in a potentially inappropriate forum, too! Please point
us to the best place for this discussion, if necessary.
I think your message is interesting but can be condensed to the following
observations:
1. Sharing packaged software within the distribution channels is harder than
it ought to be. Everything has to meet exacting quality standards, even
though some software would never be a first-class package in a distribution,
and this creates a barrier to sharing.
2. Packaging software for convenient consumption is harder than it ought to
be, and it involves an unending amount of work if the software is to reach
everyone.
3. Finding and installing software is harder than it ought to be.
To create a second tier for "apps", thus avoiding the quality paperwork around
package approval, you've advocated the following:
> To get there in GNU/Linux, I'm recommending that a basic "app" run in
> a chroot and permissions jail, with hard links to the exact shared
> libraries with which the app was originally built and tested.
> Multiple copies of any given shared library only need to be on the
> disk once. Apps could have their own /usr/lib directories for their
> shared libraries, but on the actual disk it should be
> /Apps/MyStupidFartApp/usr/lib/libsndfile.so.whatever. This would keep
> MyStupidFartApp from colliding with my friend's competing
> BiggerAndBetterFarts app, as we're likely to want to install a
> /etc/fart.conf. Later, when my friend submits a patch to libsndfile
> which gets included in Debian, it totally breaks my poorly tested fart
> app. Why should my popular fart app suffer because it has bugs that
> were sensitized by a new libsndfile shared library? If we just run
> them in their own jails, and never upgrade their shared libraries
> (except in sever security situations), that fart app should continue
> to run for decades. Why should I go through the Debian packaging and
> review process to share a stupid buggy fart app? Why does Debian stand
> in my way?
I guess this is a bit like various application directory implementations that
have been around for a while, like Klik:
http://en.wikipedia.org/wiki/Klik_%28packaging_method%29
One major pitfall of many of these approaches is that an end-user without
administrative privileges is often excluded even from installing applications
made available in this way. I have investigated various approaches involving
actual Debian packages and fakechroot in order to empower non-root users, and
I think that such considerations would have to be part of any eventual
solution.
On the subject of packaging itself and the pain of targeting multiple
distributions, you wrote...
> Therefore, to get back to the bazaar, we have to allow apps to ship
> with the various binary libraries that are not included and compatible
> in every distro. When my fart app loads sound files, it should use the
> exact compiled binary of libsndfile and all it's dependent binaries
> all the way down to libc6 that it was tested with by the author. This
> way, the app will run on every recent Linux distro.
To an extent a chroot solution will only get you so far, in my experience, as
there can be other factors that make libraries incompatible. And I guess that
initiatives such as LSB only go so far to preserve binary library
compatibility, anyway. It also seems to me that build tools have become more
in conflict with packaging tools over time, but I'm sure there are many
people with Debian packaging experience who can relate more detailed
experiences about such matters than I can.
On the subject of finding applications:
> We need a cross-distro App Center, where software can be published
> with zero or minimal review, and then run on any GNU/Linux platform.
> There has been efforts in this direction recently. The Zero Install
> guys are making good progress, for example. There was a meeting
> recently where various distros discussed a cross-platform package
> installer, but it ended in everyone agreeing to continue with business
> as usual with a band-aid on top that wont make any difference.
I think Zero Install is an interesting solution, but I also think that it
would be beneficial to leverage existing packages. Here, we need to separate
the orthogonal concerns of packaging, distribution and installation. As I
noted above, if it merely becomes possible for an unprivileged user to
install proper Debian packages in a sandbox, then significant benefits are
already gained: in many cases, the alternative to such users is a build from
source of a hierarchy of dependencies or to use an inferior solution like
easy_install (the Python package installer), which means that they are
already missing out on existing distribution facilities without even
considering the universe of unpackaged software.
Paul
Reply to: