Weekly Edition
Return to the Distributions page
| |||||||||||||
An Early Look at Progeny Debian 2.0
Remember Progeny Debian? It was a Linux distribution that set out to cure the
ails of Debian proper, such as its unattractive installation program, many
tedious steps requiring detailed knowledge of one's hardware, the unintuitive
interface of dselect, and other annoyances that were seen as major
obstacles in the way of wider adoption of Debian (and Linux) among the
computing public. When Progeny released version 1.0 in April 2001, many users
were impressed: "I really want to point out that this distribution was
very, very easy to install. My first installation just awed me..."
wrote
one reviewer.
The project was buried some 6 months later. Ian Murdock, the founder of Progeny (and Debian) explained:
From a business perspective, our customers consistently ask for
Debian, not Progeny Debian, and while Progeny Debian is technically just a
'release' of Debian (akin to 'potato' or 'woody' from the Debian project),
the appearance of maintaining a separate or 'forked' version is a
liability.
The company itself survived by switching its focus to providing services and commercial support for the Debian distribution. Then this week, all of a sudden, Progeny announced the release of Progeny Debian 2.0! Why the sudden revival of the Progeny distribution, rejected 3 years ago as a liability? Of course, Linux has come a long way since 2001 when it was a lot harder to sell. More importantly though, Ian Murdock has been promoting a radical new idea, a so-called "Componentized Linux", as a novel way of developing a Linux distribution as a collection of components, rather than as a monolithic whole. Progeny Debian 2.0 is the first released based on the concepts of Componentized Linux. Before we go any further, let's try to explain these concepts: what exactly is Componentized Linux and why is it better than the traditional development model? In doing so, we'll skip the definition on the Componentized Linux home page, which is too abstract to make an impact, and go straight to the directory listing the currently available components:
The components can be added to /etc/apt/sources.list like this:
deb[-src] http://archive.progeny.com/progeny/linux cl [components]
Each component represents a collection of packages. We can see a number of base components, such a linux-2.6 or lsb-2.0, essential for a core Linux system, and also a number of specialized components, e.g. audio or graphics. The important point of this "componentization" is that all components are self-dependent, in other words, all dependencies must be satisfied within the component itself, or a component has to explicitly specify another component that it depends on (e.g. one cannot install the gnome-2.4 component without one of the xfree86-* components). It should be noted that this componentized structure is completely transparent to the end user. Taking Progeny Debian 2.0 as an example, the user can simply apt-get install or apt-get remove any package without having to think about the components; in fact, there is no way to install or remove an entire component with one command. The "componentization" only affects developers, it affects the way package maintainers create binary packages. For example, let's take a complex package with many dependencies, such as GnuCash. In standard Debian, the GnuCash package merely specifies which other packages must be installed on a system prior to installing GnuCash. However, in Componentized Linux, the developer will have to create a "gnucash" component, with all the dependent packages either inside the component itself, or specified in another component (such as the gnome-2.4 component). How will this makes things easier and better? The way Ian Murdock envisages the role of components is that package maintainers will be able to create logical entities for specific uses. As an example, if a group of developers in Japan decides to add Japanese language support to a distribution, all they need to do is to create a complete self-contained component providing all packages needed for the language support. The component would include an input server, fonts, dictionaries, spellchecking applications and other relevant packages. Although it is hard to quantify the benefits of such approach until we have more exposure to the technology, there is no denying that a componentized structure does sound more logical, not to mention portable, than the present system of thousands of individual interdependent packages found in Linux distributions. If you are interested in trying out this approach, Progeny Debian 2.0 provides an early taste of things to come. It is an alpha release, so expect a few problems here and there, but the cl-workers mailing list is a good platform for discussions, both technical and philosophical. Besides seeing the "componentization" effort in practice, the release is an evidence that the developers have put a lot of effort into the Anaconda for Debian port - unlike Progeny's early ISO image from 2 months ago, it is now possible to install the distribution in text mode. Also of interest to some should be the Progeny-enhanced version of apt, with support for SSL/HTTPS, HTTP cookies, interactive authentication, and redirects. Although at present only Debian-based components have been created, the developers are planning to build components based on Fedora Core in the near future. (Log in to post comments)
An Early Look at Progeny Debian 2.0 Posted Apr 15, 2004 10:36 UTC (Thu) by fergal (subscriber, #602) [Link] Is it correct to compare a component with Bundle on Perl's CPAN? A bundle is an abstract package. It contains no code, it just lists some dependencies. So when I ask the cpan tool to install a particular bundle, it goes and installs all the dependencies and then it's finished because the bundle itself has no installable files.If that's not how Debian's components work, then maybe it would be worth considering as a nice way of doing things. It would also allow installing, removing and upgrading of components with a single command.
CPAN Bundles Posted Apr 16, 2004 19:33 UTC (Fri) by hummassa (subscriber, #307) [Link] No, in reality the CPAN bundles have their counterpart in "virtual packages". Virtual packages are packages that have no content, only dependencies.The "components" are groups of packages that *preferently* have few dependencies outside their group. This has the advantage of granularizing the releases, as in "we can release only the GNOME component, without waiting for the release of the KDE component".
An Early Look at Progeny Debian 2.0 Posted Apr 22, 2004 13:44 UTC (Thu) by leandro (guest, #1460) [Link] Perhaps I am just stupid, but how are these components an improvement? Perhaps they'd be for a lesser distro were dependencies are broken, apt hasn't been ported, or repositories aren't available, but in Debian I just to aptitude install evolution and I have everything I want.Perhaps the idea here is to distribute the packages outside the repositories or CDs, so that one could install something like Oracle or DB2 in a single-file component without loosing package granularity?
An Early Look at Progeny Debian 2.0 Posted Apr 22, 2004 17:22 UTC (Thu) by ArsonSmith (guest, #5695) [Link] Imagine a sources.list like this:deb http://ftp.us.debian.org/debian/ stable base xfree86-4 or something similar. It may allow the build system to automate backports of componets if possible. Although I don't really know. I do think it will make it much eaiser to update a single component, but as the article says, the user will see very little if any changes. It is the deveopers that will benifit.
|
|||||||||||||