> -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. We have: 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. What if: 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 that distribution. 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 download directory. 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 transparently. 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. :) Cheers, -- Konstantin Ryabitsev Zlotniks, INC "Выслухаў мядзьведзь казку і адарваў сабе хвост." -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
