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

Bug#813850: RFS: amanda/3.3.8-1 -- Advanced Maryland Automatic Network Disk Archiver



One more iteration.


On 09/03/16 20:11, Mattia Rizzolo wrote:
> On Mon, Mar 07, 2016 at 09:27:20PM +0000, Jose M Calhariz wrote:
>> On 29/02/16 23:09, Mattia Rizzolo wrote:
>>> * guessing you are using git-buildpackage, why didn't you just
>>>   `gbp import-dsc` to import the NMU?
>> My changes are older than the NMU.  So I did not tried to import the NMU.
> umh, yes, otherwise you'd have needed to the re-apply the commits on top
> of the import.
>
>>> * the *.dirs files don't need to list directories for files installed by
>>>   other dh_* things, so I'm confident at least line 3,4,5 of
>>>   amanda-server.dirs are useless, haven't looked at the others
>> The debian/rules relies on cp and install to copy the files into the
>> directories listed in *.dirs
>> I don't like, I would prefer the format:
>>  mkdir $dir && cp $file $dir
>>
>> What you recomend?
> there are several reasons to prefer using dh_* tools to do that.
> for the basic example of `mkdir $dir && cp $file $dir` the better way to
> do it is to add a .install file with just '$file $dir' and it'll just do
> the work.
>
> That said, I'm now sure that you don't need those lines (as in, I
> removed them and it just works, after moving to dh_lintian(1)).
>
> please try to have a look at all of the things in *.dirs and see if
> really them all are needed.  there are not many install(1) or cp(1) or
> mv(1) calls that needs them (sure, there are other things that do,
> though).

I managed to remove some lines from *.dirs.

>
>>> * I'm not happy with the old style rules file, but guess I can't ask
>>>   that much in this case, and I can live well with it anyway :)
>> Thank you.  This package is being tested on my backup server for some
>> weeks.  I don't want
>> to make changes that may invalidate my tests.  The version 3.3.9 is all
>> ready available and I
>> can change the rules style for amanda 3.3.9.
> ok.
> Just, I'd love to show you that several stuff you do manually can be
> instead done by some tools that are already there since a lot of times
> and really do the job.
> * cp of config.{sub,guess}: there is dh_autotools_dev since a lot of
>   times, since mid-January there is the "native"
>   dh_update_autotools_config(1) which is also run automatically by
>   dh(1)
> * some of the stuff done in the clean target are done by
>   dh_auto_clean(1)
> * that cp ChangeLog should already be done automatically by
>   dh_installchangelogs(1)
> * all those lines to install lintian should be just done by
>   dh_lintian(1) (just rename the *.lintian to *.lintian-overrides); for
>   avoidance of doubts, this one thing I want to see changed, the other
>   can wait for the time you'll rewrite the thing :)
>
>> This is for today.
> yeah, one step at time.
>
> Some more things from d/rules:
>
> * that $(shell pwd) can be $(CURDIR)
Done
> * you should remove the config.{sub,guess} you copy over
Done
> * what's that "source diff" target?? seams some old things that does
>   nothing now, maybe it can be removed?
Done
> * do you know why dh_makeshlibs is called with --noscripts?
It silence a lintian warning "amanda-common:
postinst-has-useless-call-to-ldconfig"
> * the -l of that dh_shlibdeps should be uneeded.
Done
> * that fiddling with substvars seems to be uneeded: whilst something
>   does put amanda-common in *.substvars in shlibs:Depends, something
>   else in dpkg merges that dependency with what you already specify in
>   d/control and keeps the one more restrictive (the versioned one you
>   specify in d/control) => 4 lines less.
Done
> * on a site note, do you know that the nice thing of using variables
>   with only one letter in a makefile makes possible to just use $c
>   instead of $(c) ? :)
I don't like that and I don't like this 3 variable names, so they will
go away on next upstream release.

>
> more:
>
> * d/copyright looks outdated, at least with regards to years.  Also, I'd
>   love to see a DEP-5 compliant copyright file
I don't know how to identify what license is used on Amanda.
I don't know what license was used to create the debian package.  Should
I contact the previous
DD that worked on this?

> * may you rename d/docs to d/amanda-common.docs, just for clearity?
Done

> * please add DEP-3 compliant headers to the patches lacking it, it's
>   otherwise uneededly difficult to understand what a patch is for (and
>   also just "Description: fix blalba." is annoying, really some
>   description ought to be loger with a sequel "by changing foo to bar so
>   that blabla can do incredible stuff and so build again", but this is
>   not required for my sponsorship offer, just a nice to have in a
>   future, maybe; also I guess the newer upstream will for sure drop some
>   patches, so this may become moot soon! ;))
>
>> Tomorrow I will look into "lintian -I --pedantic"
> yes please :)
>
>
> With the fix of some lintian tags, I think this is about all I'd like
> before sponsoring this.

Kind regards
Jose M Calhariz


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: