Bug#767754: [lintian] new check: file-in-root-and-usr

[Bastien ROUCARIES <roucaries.bastien@gmail.com>]

On Mon, Aug 17, 2015 at 11:03 AM, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Wed, 2015-08-05 at 13:35:08 +0200, Bastien ROUCARIES wrote:
>> Guillem could you get a glimspe a this bug?
>
> Be warned, I've only spent few minutes thinking about it, so I've
> probably missed several things.

Thanks guillem

>> On Wed, Aug 5, 2015 at 12:13 PM, Marco d'Itri <md@linux.it> wrote:
>> > On Aug 05, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
>> >> And this link should removed a deinstall time and you do not give
>> >> example for migration and check for dpkg-divert ... So your
>> >> description is not complete... Could you give exact script snippet to
>> >> use ? Better could you in parallel create a
>> >> dpkg-maintscript-helper in order to avoid common error ? The
>> > Do you really think that this is needed, considering that I have already
>> > opened bugs with patches for all the affected packages?
>> > (Only zsh uses dpkg-divert, and I do not know how to handle this case.)
>>
>> Yes I think it is needed, but maybe guillem come with another ideas.
>> Do you have an usertag for tracking bug you have already openned ?
>
> I don't think the operation is generic enough (i.e. not encoding
> policy, like paths) to fit in dpkg-maintscript-helper. Although if you
> can come up with a generic implementation, I'd consider adding it.

I perfectly understand what you means about dpkg-maintscript-helper.

The first step is to create code snippet that work and are robust. For
(/usr)./bin the code is not robust so marco could you go to teh
blackboard ?

Lintian would rather not suggest something that is error prone and fragile.

>> For dpkg-divert I do not know how to handle I could be different
>> depending the cases.
>
> Yeah, I guess it depends on the purpose. The problem is that
> diversions operate on files that are shipped by packages, and do not
> allow stacking so…
>
> Bailing out in preinst (or similar) might avoid possible breakage, but
> it seems rather harsh.

Yes seems the safest path. And could be upgradable if needed.

>> >> Moreover for library why do we need to create the symlink ? I think
>> >> one library shadow another and is still a bug. In this case you should
>> >> duplicate the tag and create a new tag for library.
>> > I do not understand your comment.
>>
>> I means that binaries under s?bin and libraries are different beast. I
>> think the solution for library is to not use symlink (and delete one
>> of copy) because LD_PATH is always used whereas for bin you could call
>> it directly.
>
> Right.

This part is non contreversal. So marco could you cook a patch
detecting duplication between /lib and /usr/lib (including directory)
and raising an error. This is a plain bug.

It will serve as a basis for further test for /bin cases.

>
> In addition, from what I've seen from the submitted patches, I'd
> probably check for the ownership of the pathname being symlinked to
> or removed, and if it is owned by another package bail out. Because
> dpkg will not be performing such checks at unpack time.

Marco it is up to you for this part. However I could help if needed.

Thanks guillem for your quick review

Bastien

> Thanks,
> Guillem