Re: more comments on DDP policy
Javier Fernández-Sanguino Peña <firstname.lastname@example.org> 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
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
The upside of pkg splitting by language:
- smaller pkg size
- harder for maintainers
- more possibilities of bugs
- more work for archive maintainers (kinda)
- confusion for users
...Adam Di Carlo..<email@example.com>...<URL:http://www.onshored.com/>