One more iteraction. On 07/01/16 14:31, Mattia Rizzolo wrote: > On Sun, Jan 03, 2016 at 08:23:34PM +0000, Jose M Calhariz wrote: >> On 03/01/16 13:21, Mattia Rizzolo wrote: >>> 43: override_dh_auto_install: >>> 44: dh_auto_install >>> 45: dh_install >>> >>> instead please override only dh_install, no need to override >>> dh_auto_install. >> Not certain I have done the right thing here. But I tested and did not >> change a thing. > yeah, it doesn't change the outcome, but it's 1) one line less in > d/rules and 2) more correct. > >>>>> multiarchifying a lib can be hard. But I don't think this is going to >>>>> be that hard. If I were you I'd just try to use dh_auto_configure >>>>> instead of plain ./configure call, and bump the debhelper compat. >>>>> See https://wiki.debian.org/Multiarch/Implementation for some hints, >>>>> note that that page has some outdated bits (but we all hate keeping docs >>>>> up to date :( ) >>>> Did I get it right? >>> looks good to me. though I see there are files like >>> ./usr/lib/x86_64-linux-gnu/rep/rules.mk >>> that might be used by other packages. >>> but if that one is a makefile, why is it under /usr/lib ? >>> >>> I need to try a piuparts run, and see if everything is right. >>> Since there are only two r-deps once this package is more ready I'll try >>> to build them against this, to see if this multi-lib change affects >>> them. >> And I intended to adopt that two r-deps. What should make it easier. > Indeed, I'll probably double check this particular bit another day. > > Given that now librep16 is multiarch-able, you should add a > 'Multi-Arch: same' field in d/control for it. Done. >>>>>>> * librep-dev.links => no, please. linking /usr/share/doc/<pkg> >>>>>>> directory ain't nice at all, why is that in first place? >>>> The file librep-dev.links is gone, but the links are still present. I >>>> don't know why :-( >>> those links are caused by the --link-doc option of dh_installdocs. >>> well, I'm not a fan of --link-doc, I really see too little point in it, >>> int this case you just save some kB, just gaining troubles. >>> But give that the current state of librep is a mixed (every binary have >>> linked docs to librep9, except rep-doc), I'll leave the choice to you. >>> Your choises are: >>> * remove --link-doc for rep-doc, then you can just go on >>> * remove --link-doc altogether, then you need a bunch of .maintscript >>> files (see dh_installdeb(1) and dpkg-maintscript-helper(1) >> I will do this. But need time to reread the docs. Moved to TODO file. > I tried to do this, you can find attached a patch that seems to do this > transition correctly. Done. > >>>>>>> + I see there already are preinst snippet to remove the directory. my >>>>>>> reaction to this is: wtf? it does so quite unconditionally and -.-' >>>> I changed the maintscripts to something I think is more sane. >>> I'm not sure what would be the idea behind librep16.preinst ? why do you >>> remove the symlink of librep9 ? >>> I haven't tried, but I think that directory goes away when deinstalling >>> librep9? > yes it does. So, can you explain why you did that? Removed the librep16.preinst > > > Something more: > > * d/copyright: > + there are 3 spurious line on top, not adhering to DEP-5, also they > are redundant. Please move Mikolaj email address to the debian/* > stanza and remove the lines Done > > + umh, is the Upstream-Name really 'sawfish'? Isn't it 'rep'? Done. > * d/control: > + vcs-field-not-canonical — please fix it Done > * is there a way to fix debian-rules-ignores-make-clean-error ? > > I found the problem, Done.
Attachment:
signature.asc
Description: OpenPGP digital signature