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

Re: Another multiarch decision

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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: