Re: [MoM] ProbABEL packaging
On Tue, Dec 10, 2013 at 03:09:46PM +0100, L.C. Karssen wrote:
> >> So git push --tags will do the job.
> >
> > Yes.
>
> Done.
:-)
> > override_dh_installdocs:
> > dh_installdocs
> > find debian -name INSTALL -delete
> > rm -f debian/$(DEBPKGNAME)/usr/share/doc/$(DEBPKGNAME)/COPYING
> > <whatever method to remove you prefer>/LICENSE
> >
> > Just pick your favourite method to remove the files manually.
>
> Thanks, that cleared things up for me. As to the question below, as you
> say, this is solved by your suggestions.
Please note: I'd always recommend to use "rm -f". The rationale is
that upstream might either stop installing a file (like INSTALL - which
is actually stupid to install since the user has passed this step at
this time and it becomes redundant) or rename a file and this will break
your build process if the file you try to remove is not there. You
might argue that you actually want it to break to notice the change which
is fine - just take this as recommendation.
> >> Also, in order to fix the name of the ChangeLog.gz file to changelog.gz
> >> I tried adding
> >>
> >> mv usr/share/doc/probabel/{ChangeLog,changelog}.gz
I have seen this push now and I see that you have really choosen this
syntax. Without trying this looks like a bashism and in fact when using
pbuilder (see below) - which has a minimal chroot and thus no bash -
this fails with
mv: missing destination file operand after 'debian/probabel/usr/share/doc/probabel/{ChangeLog,changelog}'
Try 'mv --help' for more information.
So the clean solution would be to use
mv debian/$(DEBPKGNAME)/usr/share/doc/${DEBPKGNAME}/ChangeLog \
debian/$(DEBPKGNAME)/usr/share/doc/${DEBPKGNAME}/changelog
and the very picky solution would be to
rm -f debian/$(DEBPKGNAME)/usr/share/doc/${DEBPKGNAME}/ChangeLog
and use
override_dh_installchangelogs:
dh_installchangelogs ChangeLog
since this makes clear we are dealing with a changelog here. I do not
insist on the picky solution - just mentioning it for the sake of
mentoring.
> What I assumed was that variables like DH_BUILDDIR existed (instead of
> debian/$(DEBPKGNAME).
There is
debian/`dh_listpackages`
which I personally try to avoid since as you can guess from the plural
it will return more than one package name in the case of multi binary
packages and it comes to likely that we might switch to this -
specifically in the probabel case where we have this "large /usr/share"
lintian warning. So I injected the DEBPKGNAME variable into the
packaging template (also one advantage over dh_make!) which could be
deleted if unused. But you see some of these variables might be quite
helpful.
> Changes have been pushed.
Fine.
I guess you will now work down the list of remaining lintian issues.
Feel free to ask for further advise if needed.
Regarding pbuilder: There is no need to do all test builds by using
pbuilder (or cowbuilder which is a faster pbuilder so to say) but I
upload all packages done in a pbuilder chroot and a package simply needs
to build there to make sure it will be buildable in our autobuilders
farm. So it is a good idea if you become comfortable with this
principle a bit.
I'm quite happy about the progress you are taking
Andreas.
--
http://fam-tille.de
Reply to: