[licquia@progeny.com: Progeny picax: Replacement for debian-cd]
Hello,
FYI, this has been posted to -devel and -boot. It concerns a possible
replacement of debian-cd.
I haven't yet looked at it. Feel free to try it out and make a
review on this list, I'd be interested in user feedback and I'm sure
Jeff would be interested in it as well.
Cheers,
--
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org
--- Begin Message ---
It's been brought to my attention that there's some dissatisfaction with
debian-cd within Debian, that some reengineering may need to happen, and
that such reengineering may not be able to happen soon. Given that, I
thought it would be good to alert Debian to the presence of an alternative.
Progeny has had some struggles with debian-cd also. When we started
work on Anaconda for Debian, we decided against using debian-cd for it,
and begun work on an alternative. The result is called "picax" (for
Progeny Install Creator and Archive eXtractor; if you think the name is
horrid, you didn't hear some of the other suggestions). We've been
using it to make our Anaconda CDs, and it's worked well for us so far.
Picax is written in Python. At its most basic level, it splits apt
repositories into parts, either by number of parts or maximum part size.
It can write installers to the parts via a modular extension
mechanism; the mechanism works to the extent that we have placed all
anaconda-specific logic in anaconda and kept it out of picax. It can
create source media four ways: separate (completely separate source and
binary parts, just like debian-cd), immediate (the last binary media is
also the first source media), mixed (each of the media contains all the
source for each binary on it), or none. Package ordering is handled via
order files, debootstrap, and/or asking the installer for important
packages; it is also apt-aware. As far as I can tell, it should be
architecture-independent, and even cross-architecture, although this has
not been tested.
Picax is still very new, and I expect that there will be problems should
Debian decide to switch to it. But I expect these problems should be
easy to solve. In particular, I've created aptable media for three
different Debian-based distributions, and working Anaconda install media
for two of those, including sarge.
To make picax useful for Debian, a debian-installer module would need to
be written. Writing an installer module for picax shouldn't be too
difficult; it amounts to a Python module with a particular API, which
picax calls at the appropriate times. You can see a working example in
anaconda; see http://platform.progeny.com/anaconda for details.
I haven't uploaded it yet because it lacked the source features until
very recently, but I will be uploading it very soon now that those are
done and tested. In the meantime, you can get picax from Progeny's
Subversion server:
svn checkout svn://svn.progeny.com/anaconda/picax/trunk
The package architecture is mature, so you should be able to build
packages from the above in the usual way.
In none of this do I wish to impugn the good name of Raphael Hertzog or
of his creation, which has served Debian well thus far. Nor do I wish
to impose my preferred solution upon Debian. It may be that fixing
debian-cd is the best course of action for Debian to take. But I think
picax could be a very useful replacement, and I wanted to ensure it was
considered. Whatever Debian decides, picax fills an important niche at
Progeny, and will continue to be useful there.
Picax development is discussed on the anaconda-workers@lists.progeny.com
list (see platform.progeny.com for more details), so please CC followup
discussion there, at least. Suggestions and concerns are welcome.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--- End Message ---
Reply to: