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 ([EMAIL PROTECTED]) 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
