On Thu, 2008-06-26 at 10:45 -0400, Felipe Sateler wrote: > Goswin von Brederlow wrote: > > > Raphael Hertzog <hertzog@debian.org> writes: > > > >> On Thu, 26 Jun 2008, Goswin von Brederlow wrote: > >>> So I think for Multi-Arch: abi packages the /usr/share/doc/<package> > >>> in its entirety should be renamed and now there is a choice to make: > >> > >> I like none of your suggestions. I'd like to suggest to rely on the > >> work done by Tollef that lets dpkg skip some files in packages. The first > >> purpose was to strip doc and locale data in some embedded usage > >> but it could be improved with new rules that exclude such common > >> name spaces for package which are for another architecture > >> than the current one. > >> > >> Cheers, > > > > So when I install iceweasel 32bit on amd64 (for stupid plugins) I will > > have no copyright, changelog nor license? I doubt that would be legal. > > Even for libaries there is no garanty that the native flavour of a > > library will be present when another architectures flavour is > > installed. > > > > If a user wants to skip them that is their problem but Debian shipping > > a dpkg that skips them allways or by default would be problematic. > > Maybe install the first one and skip the next? ie, if I install iceweasel 32 > bits first, then /u/s/d/iceweasel gets installed. When I install the amd64 > version, /u/s/d/iceweasel gets skipped. > > Another option would be for dpkg to automatically assume that each arch > Replaces: the same package for other archs, and so it will just overwrite said > files. If we are to have automated Replaces:, wouldn't it make sense to assert that the "primary arch" replaces all other architectures? i.e. in the same manner as the buildd allows Architecture: all uploads for the first upload but requires -B builds for the ports. Whichever is the primary system architecture (according to dpkg-architecture when passed no arguments) has first call on all files installed for that architecture - everything else is deemed to be replaced by the primary. In the case of conflict or Replaces: the files stay under the ownership of the primary architecture. The problem with arbitrary or sequential decisions on Replaces: is that whichever package finally gets the "flag" ends up with ownership so if the user removes the multiarch but leaves the primary, the files are not put back because Replaces: is already in effect. If users install a multiarch version without the primary version, is that something dpkg even needs to worry about? The default (to me) should be to preserve the primary architecture and ensure that if the multiarch package is purged, the primary architecture package is still in a pristine state. Allowing the multiarch to Replace: the primary will only ensure that the primary arch package is always incomplete if the multiarch is ever removed. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part