Javier Fern�ndez-Sanguino Pe�a <[EMAIL PROTECTED]> writes: > > Why is it recommended to use this numbering? Seems silly to me. > > The problem with documentation in the DDP is that (sometimes) there is no > such thing as a version in the document (or it is not really useful). Some > users might be more confident knowing the document is dated in a given > time. Take harden-doc for example (which provides the "Securing Debian > Manual"), there is no way for users to know that it's old compared to the > latest version available. > > Harden-doc (as a package) follows a different version as the manual > itself
IMHO, this should be disallowed by the DDP manual. > and, even if it followed it, a '2.8' version does not tell much to the > user. However, if the user believes the document to be updated as of > 'december 2002' he can be more confident that it's not outdated. See how I build developers-reference. I have a version of the document and the date it was updated (both derived from the changelog entry). This I think is best practice. Unpackaged manuals perhaps don't need versions but must at least report on built versions the last-modified date of the manual. > > * > > o packagename_version_all.deb > (..) > > This is the actual package which installs each language. > > > > I only mildly disagree with this. I'm thinking it's best to ship all > > languages in _all.deb. But I think it's silly to have all these -ja > > and -sp etc packages, leads to package bloat. Ideally i18n stuff is > > If we provide PDF/HTML/TXT version for all languages and don't > separate different languages then we _do_ have a problem with package > sizes. Separation also leads to users installing _only_ what they want to > need without special tweaking (such as apt-lcoalepurge). > > > shipped in a special way in the .deb files that can be stripped or > > better yet not downloaded if local configuration is against it; less > > ideal but also functional is a post-install purger akin to > > apt-localepurge. I'm looking at adding something that does this > > to doc-base once the i18n work is done. > > > That would be great but, in any case, we might not want to give > users packages which are more than 5Mbs in size. I think it might be right to have a cut-off point like this. I would object rather strenuously to a DDP policy that required pkgs split by language. The upside of pkg splitting by language: - smaller pkg size The downside: - harder for maintainers - more possibilities of bugs - more work for archive maintainers (kinda) - confusion for users -- ...Adam Di Carlo..<[EMAIL PROTECTED]>...<URL:http://www.onshored.com/>
