Re: support for merged /usr in Debian
On Fri, Jan 1, 2016 at 2:22 PM, Bastien ROUCARIES
<roucaries.bastien@gmail.com> wrote:
> On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri <md@linux.it> wrote:
>> On Dec 31, Bastien ROUCARIES <roucaries.bastien@gmail.com> wrote:
>>
>>> It is not only about lintian it is about the quality of your maintscript.
>> My maintscripts are a total of four commands and they have used for at
>> least 9 months in packages with priority important (nano) and required
>> (debianutils), with no problems reported.
>> If you believe that they are unsuitable then I think that at this point
>> it is on you to explain more clearly why.
>
> It is not a proof of non existance of black swan. And nine month is
> insuffisant for eprouved by time and you have only a popcon of 3...
>>
>>> Moreover you do not
>>> check the existance of dpkg-divert in
>>> https://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/convert-usrmerge
>>> This is a RC bug to continue if they are dpkg-divert in place.
>> Any bugs that may be in the usrmerge package are not related to merging
>> the new lintian checks, but if you could explain in more detail which
>> divert-related issues you are thinking are affecting convert-usrmerge
>> then I will be happy to address them.
>
> Ok if a target or src file is a dpkg-divert it means admin has done
> some override.
>
> You do not know admin whishes so best is to stop in preinst step.
>
>
>>
>>> Moreover quoting guillem and me about creating symlink for library
>>> under /lib if a pakage install both file in /lib /usr/lib
>> Now I get this part: I will split the lintian check in two.
>>
>>> >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.
>>> Thus we want to check if the dpkg maint script applied in case of
>>> conflicts are good. And it is not a lintian problem.
>> This would add a lot of complexity for no obvious benefit: please
>> explain more clearly what this would solve.
>
> See with guillem.
>
> And could be possible to get on the wiki page the maintscript snippet
> used by maintscript of package with conflict file. Guillem and me will
> like to review your work.
For instance maintscript suggested here [1] is totally buggy:
* postrm is buggy because you do not check if link target is
consistant with postinst
* postrm is buggy because you do not check for existance of
dpkg-divert of /usr/sbin/load_policy
* postrm is buggy because you do not check if /sbin/load_policy is
owned by policycoreutils
* postinst is buggy because you do not check if /sbin/load_policy is
owned by policycoreutils
So please get some review
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767930
> Bastien
>
>> --
>> ciao,
>> Marco
Reply to: