On Monday 23 May 2005 01:02, Javier Fernández-Sanguino Peña wrote: > Attached is a patch in order to introduce some information in the > Release Nots on how to detect obsolete packages after an upgrade. The > patch is actually made up of two parts: > > - a section right after the upgrade that details how sysadmins can > detect obsolete packages (either removed or dummy packages) in the > system. It is also targeted at warning sysadmins that security support > for removed packages will only last as long as security support for > woody lasts [1] This looks useful. Maybe it could also be intergrated in chapter 5, although that would mean changing the title and moving all existing sections one level down. > - a section in the end that is actually recovered from CVS and needs to > be reviewed. Rob updated the content but then removed it altogether in > revision 1.5. I agree with Rob. The lists are long and ugly, especially in the PDF/PS/TXT versions of the Release Notes. I'm sure that some (although I would guess a small minority) of users may find them useful, but IMO including the lists in the Release Notes is not the best way to make them available. Maybe a separate webpage can be created that has these lists. I'll be happy to include a link to those pages in the Release Notes. Also, your patch still includes: <p>The alternatives field lists any packages that might replace the removed package.</p> Now, if there really were alternatives listed, that _would_ make the list somewhat useful. However, none of the packages has this information. IMHO, Debian has grown just too big to keep track of these kinds of changes for it's users. Let's limit ourselves to packages users might expect in Sarge but are not there and really important changes that might cause confusion. Suggestions welcome. I don't expect to have the time to build these lists. If they really need to be included, they should be up to date and someone will have to compile them. > I think it's useful but maybe to unwieldy for sarge (too > many changes due to the time in between releases), maybe it's best if > we commented it out (it could prove useful for sarge -> etch if the > release is faster). That's why I have not referenced it from the > previous change. Personally, I doubt it. Even then the actual lists should be defined in entities outside of the main sgml file. The lists are hell for translators otherwise. Cheers, FJP
Attachment:
pgpzXaJDxQszK.pgp
Description: PGP signature