Packaging idea (Re: What next?)
mricon at gmail.com
Thu Jun 2 03:01:14 UTC 2005
> -jef"i think its time for someone to build their own distro using the
> packaging paradigm they like the best"spaleta
So, check this out. I'm going to brainstorm outloud, so feel free to
shoot me down at any point.
1. People seem to like Apple's idea of dragging and dropping a
self-contained application folder into their Applications window, and
see it magically work. Of course, this is a horrible idea, since it
leads to the wonderful situation of a gajillion versions of libz and
libxml being installed, all in different levels of (un)patching. The
appeal, however, seems to be related to drag-and-dropping and seeing
it magically work.
2. Yum has leet magic powers to install software, tracking all
necessary dependencies via RPM libs, as long as the packages are a)
not broken and b) not built for another distro.
3. Yum has leet magic powers to update installed software via various
repositories that anyone around the world can create and maintain,
above exceptions a) and b) nonwithstanding.
We create a "super-package" that is effectively a yum .repo file with
a little extra information, and which can additionally contain a set
of packages. Let's call this Fedora Active Package (FAP). Let's say I
want to package my FlyingCows screensaver for Fedora, and I don't
actually want to bother with Extras, since that's way too much
trouble. So, I create a FlyingCows.fap, which is a zip archive
containing the following files:
1. A manifest describing the software I am packaging, which would
include a brief description with licensing information, which
distribution(s), which arch(es), and which version it is for (Fedora
Core 4 i386), maybe some other stuff like packager info. The manifest
would also link each distribution information with the .repo file for
2. FlyingCows.png to use for representing the package in, say, Nautilus.
3. A FlyingCows.repo file for yum. There may be more than one if more
than one distribution is handled
4. Optionally, FlyingCows-1.0.0-1.fc4.i386.rpm and any additional
libraries it depends on, all packaged snugly, which is useful for
giving out CDs, for example. FAP packages containing actual binaries
can be called .fab.
So, I package FlyingCows.fap and put it on my site. A user, wanting to
install my l33t screensaver, comes to my site and downloads
FlyingCows.fap onto their desktop. Then, they open the apps://
pseudo-folder in Nautilus (similar to, say, fonts://), and drag the
FlyingCows.fap there (or just double-click the package, which is the
same). Once this happens, the following things would occur:
1. A package information screen would pop up, containing
pre-installation information for the FlyingCows screensaver, like the
license, packaging info, etc. At this step a very basic distro sanity
comparison would be done, with a warning and a refusal if the user's
distribution is not packaged for: "You are trying to install
FlyingCows on a distribution that is not handled by this package
(Fedora Core 1). This package can only be installed on the following
systems: Fedora Core 3, Fedora Core 4, RHEL 4, CentOS 4). Install
cannot proceed." If Distribution does check out (a .repo file exists
for it), then installation goes on.
2. A user clicks "YES" on the license agreement.
3. The FAP handler installs the .repo file and, if there are any
binary files in the package, installs them into
/var/cache/yum/[repoid]: in other words, pre-populates the yum
4. At this point yum is invoked, which handles the actual installation
-- including key download and verification, library dependencies, etc.
If there are newer versions available in my FlyingCows remote
repository, it downloads the latest versions and installs them instead
of the bundled binary files (optionally asking the user if they want
to do that).
5. If everything succeeds, a "FlyingCows is installed" is presented to
the happy user.
When the user gets tired of the Flying Cows, they can go to their
apps:/// pseudo-folder and drag the FlyingCows.png into the trash.
This would fire up the FAP handler and do a yum erase on the packages
installed by the FlyingCows.fap, which happens completely
What do you think? Xingbuxing? There are drawbacks to this, of course,
but I can't think of any ones that we don't already have, like
generally broken packages and whacky packagers. Having a super-package
like a .fap or a .fab would allow vendors to package things for
multiple distributions by simply providing multiple .repo files, with
yum receiving the appropriate one.
Comments, please. :)
"Выслухаў мядзьведзь казку і адарваў сабе хвост."
More information about the devel