Re: Progress on the Hurd CDs, E series.
On Thu, 11 Jan 2001, Marcus Brinkmann wrote:
> On Thu, Jan 11, 2001 at 12:21:37AM +0000, Philip Charles wrote:
> > 1. Should the dependency checking be disabled? (I would suggest yes).
>
> Do you mean the checking in debian-cd? I hope not that you mean any checks
> in dpkg or dselect :) We certainly want to fix all dependency problems. Most
> often this is a problem of not up-to-date packages. Several people here are
> becoming Debian developers now (they are in progress), so they can upload
> recompilations and package updates soon. I am happy to provide some initial
> help how to do it correctly (there ae a couple of minor problems in dpkg
> build tools etc that require careful attention occasionally).
debian-cd normally checks for dependencies so that the first CD has no
unmet dependencies, and the same for the set. A consequence of this is
that if package cannot have its dependencies met it does not get onto the
set. This has been disabled so everything that is not excluded is on the
CDs, but packages on the first CD might depend on what is on the second.
Being one of the people in developer pipeline, the sooner the better. I
am not happy about the way I am forking debian-cd and boot-floppies.
> apt is not available. I think 0.1.9 is in the ftp archive, but this is
> horrible broken. apt 0.3.19 doesn't compile out of the box, but I tested the
> current CVS version and this works very well. We can only hope that an apt
> 0.4.x is released soon. I can make a temporary package available on
> alpha.gnu.org (now that it is clear that the next official version really
> will work), so I might just be going to do that, and alpha is on the CD,
> IIRC.
alpha is on the CD. The sooner a working version of apt is on the CD the
better. dselect is even worse than I remember it was with Rex (Debian
1.2). Right at the moment the alpha packages are duplicating some of the
packages in the official archive to dpkg-scanpackages' confusion. But
this is easily fixed as alpha is added after the official archive and so
the 'official' duplicates can be eliminated through the exclude list.
I hope that we don't have to exclude anything from alpha!!
> > 3. What should be in the exclusion list? exclude.txt will be on my
> > site www.copyleft.co.nz/exclude.txt in an hour or so. It will be able
> > to be accessed from the bottom of the index page. Comments please.
>
> As we are with two CDs already, I don't think anything should be excluded
> for technical reasons. We can save some space by excluding obviously silly
> packages which are not installable (let's say, everything that is not
> installable and of priority optional or extra). Something like that.
>
The top of my list is task-* packages. We have two manual tools to
determine what goes onto the CDs; ../tasks/Debian-sid (renamed from
Debian-potato) which determines the order in which packages are put on the
CDs after the high priority ones; and exclude - which excludes from the
set. I have not got round to looking at tasks/Debian-sid yet.
> When this feature is available, we can start to file bug reports against such
> packages (makedev: linux-all, modutils: linux-any etc etc). This will clean
> up a lot of the mess.
I look forward to this as we will then be able to reactivate dependency
checking. In the meantime we are making progress by identifying what is
messy.
Phil.
-
Philip Charles; 39a Paterson St., Dunedin, New Zealand; +64 3 4882818
Mobile 025 267 9420. I sell GNU/Linux CDs. See http://www.copyleft.co.nz
Reply to: