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

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



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.

> 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.

> 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.

> >> 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.


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.

Thanks,
Guillem


Reply to: