On Mon, Aug 17, 2015 at 11:03 AM, Guillem Jover <guil...@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 <m...@linux.it> wrote: >> > On Aug 05, Bastien ROUCARIES <roucaries.bast...@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