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 :)
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.
9: DEB_PREF = $(shell gcc -print-multiarch)
umh... just use DEB_HOST_MULTIARCH instead ?
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?
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.
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
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.
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.
> >>> * 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)
* 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...
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature