On Fri, Jan 1, 2016 at 2:22 PM, Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri <m...@linux.it> wrote: >> On Dec 31, Bastien ROUCARIES <roucaries.bast...@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
