Minor bugs in release notes

[frank@debian.org (Frank Küster)]

Hi,

first of all, please please respect the Reply-to and Mail-Followup-to. I
am not subscribed to the list, and I saw this message only because I
checked the list archives. Please send me copies!


> On Tue, Sep 28, 2004 at 02:30:20PM +0200, Frank Küster wrote:
> > Hi,
> > 
> > I have just checked out a copy of the sarge tree of the release notes
> > from cvs.debian.org, and would like to report some issues. Should I just
> > send this to the list, or is there some other place? 
> 
> You can either email it to this list or email me (robster@debian.org) as
> maintainer.

So, here it comes.

1. I checked out ddp/manuals.sgm./release-notes by anonymous CVS, but I
   cannot build it unless I prepend a "architecture=i386" (or =whatever)
   to the make command. Why cannot it auto-detect the architecture, or
   build all of them?

2. The release notes are inconsistent with respect to the recommended
   upgrade method. In Section 4.3, p. 12, it says: 

,----
| The recommended method of upgrading is to use the apt method with dselect, as describe
| here. 
`----

   I understand this as "use dselect!". However, in 4.4, p. 14, I read:

,----
| The recommended tool for upgrading between Debian GNU/Linux releases is to use the pack-
| age management tool aptitude. 
`----

   Two pages later, in "4.4.1 Possible Issues During or After Upgrade",
   I am informed: 

,----
| apt-get will alert you of this and abort the upgrade.
`----

   How can apt-get tell me something when I use aptitude (or dselect)? 

   I guess aptitude is in fact the program of choice, but this could be
   made clearer.

3. In the Appendix "Removed Packages", the bugnumber is missing for some
   packages, and, more importantly, there is no "alternatives field" at
   all, but it is advertised just above each list.

   For the packages removed because of other reasons, the text promises
   "The reason for the removal of the package is listed below the name
   of the package" which is not true.

4. mindi is incorrectly listed as "removed for other reasons" (it has
   been re-added).

5. stat is listed as removed for other reasons, but I'd say that it
   should be listed under "Renamed Packages" with coreutils as the new
   name, because coreutils provides the stat binary. It doesn't formally
   Provide the package, but its main functionality, AFAIS; at least in
   the release-notes, this information would be more useful than merely
   declaring it dead. 

I hope I didn't miss something, because I forgot my annotated copy at
home... 

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie