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

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

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.

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

I don't like the name sm, so used libname instead and dh_listpackages |
grep librep | head -n 1.

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

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

Reply to: