Re: Future of debian-cd
On Wednesday 07 January 2004 15:16, Raphael Hertzog wrote:
> Hello everyone,
> many of you already noticed that debian-cd is a bit complicated.
> And it tends to get worse since we keep doing small modifications
> everywhere without a global logic.
> Thus I think that debian-cd needs to be partially rewritten.
> Here are the main critics that I have :
> - complicated shell code in Makefile is ugly, it was supposed to
> not need to be modified, and in fact many parts of the Makefile
> were modified for various purposes
Richard idea to split it in dirs sounds good. The approaches of multiple
Makefiles/scrips which invoke each other seem similar in human efforts
to me. I would probably prefer multiple Makefiles thou.
> - you can't reasonnably build potato cd with current debian-cd because
> of those "infrastructural change" to a CD (inclusion of udeb for
> example) which were not expected at the time of my initial rewrite
> of debian-cd. I still managed to keep most of the compatibility
> but at the cost of more code complexity.
> - we have too many imbricated options which do not make sense to many
> of us, it's time to see if we shouldn't get rid of some of them
> (or at least hide them somewhere deeper than CONF.sh)
> - the official support of businesscard cd/netinst cd/dvd is not good, most
> people are not able to build such CD with debian-cd because they don't
> know how the magic combination of parameters.
> - it's too much of black magick to know the good size parameters to give
> In a new design, I would like to have :
> - a MEDIA_TYPE input variable that would tell me :
> 1 - businesscard CD
> 2 - netinst CD
> 3 - usual CD
> 4 - DVD
> The size would be taken from a default value (if not overriden).
> - a system of profile that would describe how to build a particular kind
> of ISO
> - a system of profile for debian-installer, so that we can easily
> customize the udebs used by the debian installer
> The new design should still reuse most of the existing code, not
> everything needs to be thrown. In fact I think that most should be kept
> but cleaned from the cruft and reorganized in a different way.
> Now, I'd like to hear from you :
> - what are your (constructive) critics against debian-cd ?
It was quite difficult making the debian-cd cvs version running on redhat 7.3.
I don't know how the guy that wrote he's using debian-cd to build
unstable managed to do that. Certainly not without modifications.
I've also managed to build sid images but not a bootable ones, since
there were no boot images or tasks for sid in the tree(honestly,
I've forgotten what the exact cause of that problem was).
I think debian-cd should run on any unix/linux. Some binary packages
could be provided for OSes other than debian. Not everyone keeping
a local debian mirror is running debian on that box.
I don't find jidgo suitable for "main way of distributing Debian CD images".
I've posted about that and Richard didn't succeed to argue about the
jidgo advantages over the rsync/debian-cd approach. The only use of jidgo
I find is to fetch/update the isos when the preferred mirror is not
providing an rsync access, and there's no other useful mirror nearby.
A word about the debian installer. I've tried to install sid on a recent
box with an old monitor. It was a 12" black and white with very poor
timings. In fact it is capable of running text mode and e.g. 800x600@60Hz.
Unfortunately debian installer changes the text mode timings and the
image was screwed up.
As for the scripting language I would choose perl (not willing to argue).
> - what design ideas do you have for a possible rewrite ?
> - what do you think of what i've written above ?
> - how do you think we should proceed ? should I start from a completely
> new repository and import only what I want to keep ? should we work in
> a branch of the actual repository ?
The main development line usually goes in the HEAD. No matter how drastic the
changes are. If You don't do so You will have to merge the changes back
in the HEAD at some point in the future, which I find is good to be avoided.
> BTW, as you may have noticed I have less & less time for debian-cd, and
> I'd like to have some help in the long term to help me maintain it. With
> a (partial) rewrite, it would be the perfect time for someone to step up
> and get familiar with the code ...