On 03/01/16 13:21, Mattia Rizzolo wrote: > ok, let's have a look at today's work :) > > On Sat, Jan 02, 2016 at 08:03:53PM +0000, Jose M Calhariz wrote: >> I decided to bite the bullet. Upstream already have packaging work for >> dh. As his work is GPL2 >> I decided to merge it. > oh, cool. > some things (the number is the line number): > > 2: #DH_VERBOSE = 1 > > well, not sure if without export it works the same, but I always saw > this with an export. furthermore, don't feel obliged to keep it > commented out, if you like verbose stuff in your build log, enable it :) You are right, the export keyword is very common here. I am commenting because currently I am not debugging the packaging. So I choose less verbose builds. > > 4: DPKG_EXPORT_BUILDFLAGS = 1 > 5: include /usr/share/dpkg/default.mk > > these are unneded, starting from debhelper compat 9 dh and dh_auto_* > exports them. See debhelper(7) for more info. Please consider removing > them. Done. > 9: DEB_PREF = $(shell gcc -print-multiarch) > > umh... just use DEB_HOST_MULTIARCH instead ? Done. > > 23: sm := $(shell grep '^Package: librep[0-9]' debian/control | sed -e 's@^Package: librep\([0-9][0-9]*\).*@\1@' ) > > umh, what about: > sm := $(shell dh_listpackages|grep 'librep[0-9]\+') > and then use '$(sm)' instead of 'librep$(sm)' in the rules file? I don't like the name sm, so used libname instead and dh_listpackages | grep librep | head -n 1. Done. > 26: dh $@ --with autotools-dev --with autoreconf > > using both autotools-dev and autoreconf is usually just plain wrong. > with that also please remove the build-dep on autotools-dev. > See https://wiki.debian.org/Autoreconf for more info. Done > > 32: dh_auto_configure -- $(shell dpkg-buildflags --export=configure) $(DEB_CONFIGURE_USER_FLAGS) > > that's the same as above, ther is no need to manually invoke > dpkg-buildflags starting from compat level 9 Done. > > 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. > Now, the rest of the build stuff still looks unnecessarily complex, but > it's better than before. maybe I'll try to semplify it locally over the > next days. > > >>>>> * you have a librep9.symbols, probably you should rename it, and update >>>>> to have the newer symbols, and remove the old ones. >>>>> * please bump to debhelper compat 9 >>>>> + this will also make (or at least help) make the lib multiarch-able >>>>> - for this to work you need to start using dh_auto_configure instead >>>>> of manual calling ./configure, though >>>>> - note that with this several .install will need an update >>>>> - I see you already had troubles with --host and --build configure >>>>> flags: 1) I wonder why you need --host at all, we are not >>>>> cross-compiling... 2) dh_auto_configure takes care of --build. >>>>> - suggestion: stop fiddling so much, and use dh + dh_auto_configure. >>> 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. > >>>>> * 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. > * use --link-doc also for rep-doc, then you need only one new > .maintscript for it (the dir-to-symlink one). > > at least I find --link-doc better than the current symlinks and > maintscripts... > >>>>> + 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? > >> Another iteration, can you please review it? > > I have a feeling this is going to take several iteractions :) > library packages are never easy, and this builds also something more > than just the lib... > Another iteration. Thank you for your patience. This is my first library. :)
Attachment:
signature.asc
Description: OpenPGP digital signature