[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Thoughts, experiences, ideas...RE: Debian slink CD images



On Fri, 11 Dec 1998, Jim Westveer wrote:

>slink_cd-0.6
>Thoughts, experiences, ideas
>(hopefully constructive feedback)
>
>
>TREE..........
> resc1440.bin ??? not currently in the slink archive!
> -- workaround: I used hamm/main/disks-i386
> I have not seen a 1440 boot-image in slink as yet.
> last time I tried the 1743-image mkisofs complained that the
> resc1743.bin was too big.
> is this true, or are my fat fingers at fault here;-)

The script at the moment can't be considered final - the resc1440.bin I'm
using at the moment is a hand-downloaded one from Incoming. (v 2.1.2). The
boot-floppies should hopefully be resolved soon, making this step
obsolete.

>MD5SUMS.........
> -many thousands of errors -
> I am not sure what is at fault here.
> I have a fairly stable mirror, that I use daily
> so my first thought is that the mirror is ok.  What
> exactly does this section do?

In order:

get the md5 entries for each package from the Packages file
munge this to remove the path (a lot easier than trying to match paths
	too, particularly when we're split over multiple trees)
in a temporary directory, make a set of sym-links to the actual files 
check the md5 sums for the above.

then:

grab the source md5 entries from each .dsc file
sym-link to all the source files (.tra.gz and .diff.gz) in our temp
	directory again
check the md5 sums for the above.

If you have a lot of errors, something must be wrong at your end I think.
Running it here I have only seen two errors, bith of which were from
broken downloads. Is the Packages file up to date on your mirror?

>PACKAGES...........
> Creates main-1 then main-3 (?)  is this a typo, or intended?

It's intended. Main is split onto discs 1 and 3 and we need to know the
contents of each _separately_ to generate the Packages.cd file (look at
the contents of this - it lists disc number for each package too).

> Finds many errors like:
> !! Package ktop has `Section: contrib/x11', but file is in `x11' !!
> !! Package metro-motif-bin has `Section: contrib/x11', but file is in 
>`x11'
>!!
> !! Package metro-motif-demobin has `Section: contrib/x11', but file is in
>`x11'
>
> Is this a by-product of "flatten" ?

As far as I can tell it's a normal warning from the dpkg-scanpackages
stage. The Packages files work despite this... Maybe this is a hangback
from before the other sections were integrated alongside main.

>
>BOOT........
> errors with :
>
> Copying new boot disks into place
> cp: /root/boot-floppies/*i386: No such file or directory
>
> Is this your personal workaround to the resc1743.bin problem?

Yes. See above. I should document this better, or at least make it more
obvious - ~/boot-floppies is the local place where I've downloaded the
latest boot-floppies from Incoming.

>EXTRAS........
> ok - good for repackagers

That's what I thought. And in particular there are things I want to put on
for my own uses...

>MD5LIST......
> ok
>
>IMAGES.......
> It made...
> 656248832 Dec 11 07:50 slink1.raw
> 715577344 Dec 11 07:55 slink2.raw  <<-- a bit heavy here ;-)
> 471808000 Dec 11 07:59 slink3.raw
> 684177408 Dec 11 08:03 slink4.raw  <<-- a bit heavy here ;-)
> 561004544 Dec 11 08:07 slink5.raw

Hmmm. Can you mail me some "du" output? Mine are big, but not quite that
big.

>Thoughts about Organization of disks.......
> *** Single Binary Image ***
>
> The first disk really needs to be stand-alone.
> If this is all the user receives, they should be able to build
> enough of a  system to get going.  The rest can be
> upgraded from the net.
>
> The only problem here I see is that the /net and /utils directory is
> on slink3.  I am sure that the organization of what goes on what disk
> will be a topic forever....but we should build the first disk so that it
> can be "given away" or "widely distributed".  It needs to just get
> the user up, and it needs enough free space on it to be available
> for "custom distributions".  ie. if Corel wanted to release their
> office products on a Debian base, it would be easier if there was
> enough space left on the "base" disk, for their applications. just a
> thought.

Hmmm. That'll take some significant work. It can be done, I guess. You
need to go through the Packages files and just check for the Priority on
each file. Grab the ones with required/standard priority and list them
into slink1-list and so on. I've not done that yet because I'm trying to
get everything to fit neatly; I break by section for the binaries so that
installation will be quick and the user should easily be able to find the
right CD for a given package. Maybe for the next version...

>NON-US.....
> I hate this problem.....but there is the reality....
> The "official" disks should not include non-US, as one is not
> sure where you are gointo ship the disk to.  Perhaps it should be
> on its own disk.

That's a painful way to do it; the official Hamm CDs gave you the option
of building with or without non-US and I may add that for the next
version.

>THOUGHTS ABOUT THOUGHTS......
>
>Actually I like it!

Cool! *grin* It's a gross hack but it works OK for me at least...

>I like the extra's section.
>I like the disk#-list idea, it makes changes easy.
>Your code is easily read/modified.
>Gotta make the first disk as stand-alone as possible.

Hmm, I guess so. I personally only sell/make full sets at the moment, but
I see your point.

>Gotta put non-US on a separate disk.

Maybe. Make it configurable.

Any other thoughts from other people?

-- 
Steve McIntyre, Allstor Software         smcintyr@allstor-sw.co.uk
<a href=http://www.chiark.greenend.org.uk/~stevem/comp/>My PC page</a>
"Can't keep my eyes from the circling sky,                 
"Tongue-tied & twisted, Just an earth-bound misfit, I..."  


Reply to: