[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

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 :)

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

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

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
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

> >>> * 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

> >>>   + 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

> 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...

                        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

Reply to: