X-Debbugs-CC: a...@debian.org, ballo...@debian.org, spwhit...@spwhitton.name, r...@debian.org
El dc 07 de 02 de 2018 a les 17:31 +0100, Bill Allombert va escriure: > ... However <package> will have to have a versioned Depends: on > <source package>-copyright for exactly the same reason: the copyright > file might change between versions and we do not want to confuse users > by allowing them to have an outdated <source package>-copyright package. Versioned Recommends actually, but does a versioned Recommends make any difference? The user knows there is an updated package with no dependency problems. On the other hand, when having two versions of the same package in multiarch (in the future), one of them will not match the version of source-copyright. Is this a problem? El dc 07 de 02 de 2018 a les 08:40 -0800, Russ Allbery va escriure: > Why would you not use the existing *-doc package construction, which seems > to accomplish exactly the same goal and is already fairly standard > practice for packages with large documentation directories? Flexibility: maintainer may want to provide *-doc-minimal, skip documentation build dependencies, or whatever reason. But *-doc is fine to me. > The additional metadata required for the extra packages is going to > eliminate any possible gain you would get here. I do not think so. Metadata is usually smaller than those files: copyright, changelog, manpages, etc. > > 2. It helps to solve the Multi-Arch file refcounting problem. > > We've already solved that by not allowing different versions of multi-arch > packages to be simultaneously installed. That is not a solution. The problems are described in the TimeTravelFixes page. > To relax that constraint would > require dealing with far more than just the copyright file, and would need > a more comprehensive solution. Of course, I did not claim to fix the problem, only that it helps. El dc 07 de 02 de 2018 a les 09:57 -0700, Sean Whitton va escriure: > > Do you receive my messages from the list? > > https://lists.debian.org/debian-policy/2018/02/threads.html > > Yes. I do not see them in the list. Are you sure? Did you check the mail headers? > This does not explain why it is problematic to have the (small) > copyright files additionally installed. To the user, it is not problematic because of disk usage, but there is no problem switching Depends to Recommends either. > > Yes, and package lists get bigger, I know. This scalability problem > > should be discussed elsewhere. > > Why elsewhere? Policy would be the thing imposing the problem! Does policy impose a limit on the number of packages Debian can host?
smime.p7s
Description: S/MIME cryptographic signature
