Steve Langasek wrote: > If users are not installing such packages directly, that means they'll only > be installed when pulled in automatically by other packages which already > depend on the libs or data in question; therefore, there's no need to > declare a reciprocal dependency (not that this would be meaningful in the > case of a lib package, anyway, or even in the case of many data packages). Sure there is. Making foo-data depend on foo causes it to be removed when foo is removed. Of course so does aptitude's automaticly installed package tracking, but that is more fragile, and also see the various remaining dselect users in the parent of this thread. > From a release standpoint, while we don't want -data packages to be released > without the programs that make them useful (in those cases where, for some > reason, the -data comes from a separate source package from the program), > reciprocal dependencies aren't much of an improvement currently, as they > require the release team to intervene to hint such package pairs through > into testing. Only because britney is too broken/overloaded to do a complete scan for such pairs and let them in itself. -- see shy jo
Attachment:
signature.asc
Description: Digital signature