Re: Summary: dpkg shared / reference counted files and version match
On Fri, 2012-02-10 at 17:16:29 -0800, Steve Langasek wrote:
> On Fri, Feb 10, 2012 at 06:56:00PM -0600, Jonathan Nieder wrote:
> > As long as dependencies are accurate, I don't see how allowing
> > co-installation of the same package for two different architectures at
> > different versions is any more complicated than pinned to the same
> > version.
>
> I think we're likely to see a lot of bugs introduced in the process of
> making the dependencies accurate if we go this route. So instead of
> refcounting the files, we move them to a new arch: all package. Ok; now,
> suppose some of these files aren't actually architecture-independent:
> they're data but they're generated differently on different architectures,
> and the library expects the data in its native architecture-dependent
> format. (See the parallel thread about "endianness of data files" for
> examples.) Doesn't this proposal eliminate one of our best defenses against
> this packaging error? Having them kicked back as mismatched files, either
> by dpkg or by the archive, seems better to me than letting them land on the
> user's system and break at runtime.
While I agree this is a potential issue, it's not a new one at all or
specific to multiarchified packages, it's actually inherent to every
arch:all package generated from source packages producing arch:any
binaries too, regardless of multiarch.
Instead of treating M-A:same specially on this, I'd rather see a way
to detect this for all current and existing cases instead, if deemed
really necessary.
regards,
guillem
Reply to: