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

Re: Proposed pre-depends addition: all multiarched libs -> multiarch-support



Steve Langasek <vorlon@debian.org> writes:

> On Tue, Apr 05, 2011 at 11:12:29AM +0100, Simon McVittie wrote:
>> On Tue, 05 Apr 2011 at 11:12:54 +0200, Adam Borowski wrote:
>> > On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote:
>> > > Specifically, the plan is that any package in wheezy shipping a runtime
>> > > library in a multiarch directory should declare a Pre-Depends on the
>> > > metapackage 'multiarch-support'.
>
>> > And the dependency would be added by either dpkg-dev, debhelper, or
>> > dpkg-shlibdeps rather than being added to every single library by hand,
>> > right?
>
>> Because debhelper doesn't add any Pre-Depends yet, there's nowhere to put
>> the new dependency that would automatically be picked up. I believe the
>> current plan is that:
>
>> * debhelper adds multiarch-support to a new
>>   ${misc:Pre-Depends} substvar (which must be added to the library by hand)
>
>> * this is only relevant to packages that divert files into multiarch
>>   directories, which would only happen with package-specific changes anyway
>>   (bumping the debhelper compat level to 9, if nothing else)
>
>> * lintian should warn (error?) if a binary package has libraries in a multiarch
>>   directory and doesn't pre-depend on multiarch-support
>
> Yes, it should.  I think this should actually be an immediate archive reject
> for any package installing to the multiarch lib path without the correct
> pre-depends, since (on i386, anyway) the missing pre-dep will break partial
> upgrades in a Bad Way.

Which doesn't mean one has to use debhelper or compat level 9. The
rejection should be purely on the basis of the missing pre-depends and
multiarch paths. How you get the pre-depends doesn't matter.

MfG
        Goswin


Reply to: