Re: slink_cd 1.11
On Tue, 23 Mar 1999, Santiago Vila wrote:
>Hello.
>
>[ I have been unable to get the latest slink_cd package, so please
> forgive me if some or all of this have been fixed ].
>
>Yesterday I downloaded the file binary-i386-1.iso from the 2.1r0 directory
>in cdimage.debian.org (i.e. the one having a md5sum of
>5e17befce2468a4197b81e89b2680a78), toasted it, and used it to upgrade my
>system at home.
>
>The upgrade was almost painless, but I have a lot of comments to make.
>This is a list of things that, IMHO, could be fixed from this CD:
OK...
>- There were a "frozen" symlink in the dists directory. Since
> slink is now "stable" I think a "stable" symlink should be enough.
Agreed. When the CD image was made, slink was still frozen.
>- The general md5sum.txt file followed symlinks, when this is combined
> with the previous point, the result is that the files appeared three
> times each (one for slink, another one for stable, and another one
> for frozen). Including every file just once should be enough.
Hmm, yes.
>- The md5sum.txt file included itself :-) If we know that it will
> "always" fail, it would be nicer to exclude itself from the list.
> This will avoid the user to see that the command md5sum -c md5sum.txt
> "fails" because of a single file.
>
>I think a command line like this:
>
>find . -type f | grep -v "\./md5sum" | xargs md5sum > md5sum.txt
Unfortunately, not quite. At the moment the line used is
find . -follow -type f -exec md5sum {} \; >md5sum.txt 2>/dev/null
The "-follow" is needed for people using slink_cd with a sym-link farm.
I'll see what can be done to get around this...
>- Many files in dists/slink/main/upgrade-older-i386/deb-files
> were dangling symlinks.
There were 4, yes. This is known about already and should already be fixed
for the next version.
>- There was a `*.doc' file in the doc directory.
Yes, ditto.
>This is all about the "form", now about the "contents":
>
>I used the "mountable" method to upgrade, and found the following
>problems:
>
>- I had to remove zlib1g-dev and svgalibg1-dev to be able to upgrade
>zlib1g and svgalibg1. This is because hamm's zlib1g-dev and svgalibg1-dev
>had a versioned dependency (using `=') on zlib1g and svgalibg1. However,
>since zlib1g-dev and svgalibg1-dev were not available in the first CD I
>could not upgrade the four packages at once, dselect complained
>about the unsatisfied dependency.
>
>Suggested fix: Include zlib1g-dev and svgalibg1-dev in the first CD.
>Maybe they are not very popular but upgrading them may be a real pain
>if they are in a different CD than zlib1g and svgalibg1.
Hmmm, OK. I'll add them to the "useful" list for CD 1.
>- Due to hamm's dpkg-mountable unability to handle pre-dependencies, I
>had to upgrade some packages by hand, namely libncurses4, slang1,
>libstdc++2.9 and libreadlineg2. This is of course not CD's fault, but my
>fault for not using APT :-)
:-)
>After this the upgrade was quite smooth.
OK, good.
>At the end:
>
>- I wanted to remove slang0.99.38 but I couldn't, because some packages
>still depended on it.
>
>Suggested fix: Include whiptail and modconf in the first CD.
Again, done for the next version.
>- syslinux appeared as "obsolete".
>
>Suggested fix: Include syslinux in the first CD.
>
>- gettext appeared as "obsolete"
>
>Suggested fix: include gettext in the first CD (it is an almost-standard
>package, since it is in the base system for slink).
>
>In short: It would be really nice if the first CD included everything
>which was in base in hamm or it is in base in slink.
OK, I guess so. Although people upgrading from hamm should probably be
sure to get at least both of the binary CDs, as there are quite a number
of packages that will not be on CD 1.
--
Steve McIntyre, Allstor Software smcintyr@allstor-sw.co.uk
Getting a SCSI chain working is perfectly simple if you remember that there
must be exactly three terminations: one on one end of the cable, one on the
far end, and the goat, terminated over the SCSI chain with a silver-handled
knife whilst burning *black* candles. --- Anthony DeBoer
Reply to: