How to implement bundle-like mechanism in Arch Linux

Question

I like Chakra's bundle system and I want to make it in Arch.
I heard that bundle system is just a separate file system(like loop? I am not sure).
Can you give some details?
However, I think there must be some reasons that Arch does not implement such a convenient tool as bundle system.
I want to hear about these reasons.
Thank you.

Answer 1

If you go back more in the history behind Chakra, how it came to live, you might know, it started bc of a desire to do another split.  That one was for KDE, resulting in KDEmod, which was fully accepted by Arch, a few years after, and is currently the way KDE is build in Arch too (KDE being split in multiple packages).
While Chakra was just Arch + KDEmod, more and more users stated, there was a desire to split toolkits too.  Have a system that was either based on GTK, and for Chakra users, a system base on just Qt/KDE.  When the late Chakra founder Jan Mette called the meeting in February 2010 the discuss the plans for a full split from Arch, this desire expressed by many users was one of the driving factors for his decision.
To have a fully functioning distro, and doing something this different, the discussion included finding some MacOS way of including some of the most well known, and revered Linux apps, that were GTK based.  That is how the idea of bundles came to fruit.
At the start, a few hundred packages had either makedeps  or full dependency to gtk2, so it was left up to the user to install those apps, though the ISO's were gtk free.
Once the bundles became more functional, and included all those most well known and revered Linux apps, the majority of the gtk apps were removed (slowly) from all repo's.  Plus in the good 2 years since, many apps/libs have been stripped of gtk, since many apps are build to function on both gtk and qt based systems, though they do not need the gtk libs at all to work just fine on a qt based system.  To remove gtk libs/functions from one app, makes very little difference, for ten, it is not a big difference, but you repeat it over a hundred times.....
GTK is still in the repo's, and probably will stay there.  Users who do not want to stay gtk free have added many such apps in ccr, and as a service to them, it is nice to not have to compile gtk.  Plus there is no real solid substitute yet for flash, again as a service, it is still an option.  The bundle buildsystem also draws from the repo's, if a certain lib/app is set to draw from there during the bundle process, that is another reason gtk/gtk-apps are still in the repo's.
As Allan states, downloading multiple bundles, will download multiple instance of a highly compressed gtk (or other lib/app).  This is ofc a draw back for bundles, but again, a well thought out, and chosen draw back.  Users who need more then 4-5 bundles, should really rethink using a distro that made the choice to see if a distro can be fully functional, when splitting toolkits.  Those users can install their needed apps from ccr, or perhaps should choose another distro.  But to have an application not needing a rebuild/break bc of a .so update is a big plus.  When libreoffice was not stripped of it's gtk deps, it was one of those bundles.  It included all, and one such bundle still runs perfectly on one of my installs, it was build February 2011 (granted, I'm using this one as a test case for bundle longevity).
For those who do not need but 3-5 bundles, there is no gtk installed (takes more room, then downloading it in compressed form a few times).  And many bundles do contain more then one gtk app (GIMP bundle includes xsane for example, chromium includes flash, google-talkplugin, pdf plugin), so as an example in my case, I run one bundle almost all the time, and it brings me the only 3 gtk apps I need and I my installs are gtk free.  Btw, all bundled browser include the flashplugin.
But bundles are not just for gtk, Skype is another example for bundle use.  This app brings in about 50 lib32 packages, if you are on x86_64, why install all those for just one app?  Some will state, it makes no difference, don't care to have a lot of extra libs installed, some will prefer to keep a more "clean" system.  Chakra goes with the latter.
Since the bundle process can draw from the repo's, or build all needed packages in that system, in any setting chosen, any security update is no extra work, then any other rebuild.  That security update was either done in the regular repo's, all needed then is rebundle all included apps (the final bundle process, squash them, etc, takes about 40 secs), or if the apps is not in the repo's, just that one is rebuild/adjusted in the bundle system, and again, bundled with the rest of the existing packages included in that particular bundle.
To address as a final note, the point made, you can't be bleeding edge bc of bundles.  I'll give the example of the gimp-dev bundle.  It needed the latest babl, gegl, much newer glib2, gtk2 (and more from that stack) then was in the repo's.  All those were updated in the bundle system (though not a visible repo, the bundle build system has some 200-250 packages at most times), tested and ran successfully for many users, and always making the latest dev version available for gimp, until the final release this week.  Since all glib2 updates were tested in this bundle for quite some time, when it was time for this update in the regular repo's, it was a simple and quick update for the whole stack.
Bundles are not perfect at this stage, far from it, there are still many plans to improve on the whole system, but for something that is in use just 1 1/2 years, it truly is a viable option to have a system running on a single tooolkit.
To address a question posted while writing this.  Chakra uses testing repo's a lot too.  Bundles are fully rolling, always the latest available, just like the apps and games repo in Chakra.
Last edited by abveritas (2012-05-04 18:17:43)