[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: more comments on DDP policy



Javier Fernández-Sanguino Peña <jfs@computer.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
> 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..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>



Reply to: