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

Re: Merged release notes (was Re: Errouneous link in dist upgrade documentation)



On Sun, 28 May 2000, Josip Rodin wrote:

> On Sun, May 28, 2000 at 12:26:46AM +0200, J.A. Bezemer wrote:
> > especially the <p>-surrounding of every <example>, which looks _much_
> > better in the .txt and doesn't seem to affect other output formats.
> 
> I seem to remember that debiandoc-sgml maintainer told me not do do this.

Than let him fix the text-mode output. Which can't be done any more for
potato, so we should use a workaround.

> And I don't understand why is it so much better, not even why is it
> different.

Compare this:

---------- text mode, without <p>'s
          if `/dev/hdc' is your CD-ROM drive, `/etc/fstab' should contain a
          line
               /dev/hdc      /cdrom     auto    defaults,noauto,ro     0   0
          To test this, insert a CD and give commands
----------

---------- text mode, with <p>'s
          if `/dev/hdc' is your CD-ROM drive, `/etc/fstab' should contain a
          line

               /dev/hdc      /cdrom     auto    defaults,noauto,ro     0   0

          To test this, insert a CD and give commands
----------

I've seen _many_ scientific and computer-related texts (being a student also
has advantages...), and never ever I saw something like the without-<p>'s
version. It's just a mess.

Also, even without <p>'s, all other output formats (html, ps, pdf) DO have
whitespace, so I suppose this is the way it was intended, and that it should
be that way for text-mode, too. The fact that it's not is a bug in
debiandoc-sgml or related things.

> Thanks for doing all this, although I would have preferred a straight
> unified diff (diff -u oldversion newversion). Please do that next time.

Okay. However maybe I've got CVS access by then.

> One big question: if dselect's multi_cd access method (or dselect at all for
> that matter) should not be used anymore for upgrades, as your changes to the
> Release Notes imply, the dpkg-multicd package should be removed, no? I have
> left the dselect stuff there, for now.

There is NO dselect method (except `apt') which handles dependencies at
_install_ time. (dselect does only at _select_)

Imagine the following situation: I'm doing a remote upgrade over ssh, using
for example the `mounted' method, or maybe the `multi_cd' if I'm rich enough
to have a CD-changer. Then it might just happen that ssh is upgraded before
libgmp2 (both are on the binary-1 CD now). And just between them my link is
terminated, which ssh notices and -HUPs the shell and the install process. 
The new ssh needs the new libgmp2, which isn't there yet, so I can't access my
system any more. 

Apt handles dependencies well, and will always unpack (and even install!)
libgmp2 before ssh.

This is just an example, things might be even worse. IIRC there are some pkgs
pre-depending on libc6.1, so that won't be a problem, but anything else may.

The very fact that nothing did handle dependencies at install time was the
main reason for developing apt. And also why a kludge was needed to upgrade to
2.0 with the autoup script. With apt, that's not needed any more.

So, this is why we shouldn't mention any upgrade method other than apt. Please
delete the dselect stuff as I did.

The dpkg_multicd package can be kept (at least for the moment), because it
does a relatively good job when installing additional pkgs in a "stable"
release. But it's never meant to do upgrades, and nobody should try to use it
for that purpose. 


Regards,
  Anne Bezemer



Reply to: