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

Re: Package review and comment wanted



Hej Frank,

and thank you for very much appreciated comments.
I will try to answer them below

/Bengt

Frank Küster wrote:

Did you read the new maintainers guide and the developers' reference?
Yes, I read them once, twice, and ten times, but must have some problem with my english apperantly.


That depends on the complexity of the installation. In most cases, it is
highly advisable to have a separate Makefile that does the compilation
and installation, and in debian/rules you only call it with appropriate
targets and arguments.
ok

Isn't there a Makefile in the upstream sources?
Upstream.... this is the upstream. I created the package


*) Should I list all the directories in the dirs (including /usr/sbin)


In debian/dirs, you only list the directories that you want to create
with dh_installdirs - e.g. directories that the upstream Makefiles
Ok, but when I do not create the usr/sbin directory in the debian/dirs file the dpkg-buildpackage -rfakeroot fails with taget directory do not exist or something like this. I ended up having to put ALL my expected directories in this debian/dirs file. Then the installation went very fine. But when I tried to remove the package, it also tried to remove /usr/sbin....

*) How do I automatically set the version number and perhaps a
timestamp in the program during packaging?


I don't quite understand what you mean with this. Are you speaking about
the output of your program when called with a "--version" option?
Yes, the output from buppo --version.
I do not as of right now anyway, use cvs or subversion to handle my revisions. But simply relying on creating a new debian package every once in a while so I have something usefull to go back to. I ended up doing a hack in the Makefile to modify the source code (which I really do not want to do)

So it does have an upstream Makefile - use it.
I created this Makefile as well, after some people complained that I should not try to remove /usr/sbin when they removed the package.


You are packaging this as a Debian native package. You shouldn't do
that, unless there is good reason why nobody outside Debian would want
So, if I am the one who creates this package, should I not create the package as a Debian native package?

to use it. This is true for packages like debian-policy or apt-get (or
perhaps not even for that one), but most probably not for a backup
program. Consequently, you should use the manpages out of the debian
directory and install them in the Makefile.
The Debian man pages are located in the docs folder as xml files, and compiled into man pages in the debian directory in the Makefile.


You should probably look up what people mean with the difference between
differential and incremental backup; it seems as if you provide both
possibilities.
Good point :-)


In the description you say that it uses afio and tar, but you don't
depend on tar.
Lintian complain when I was depending upon tar.


The changelog entries are not really well understandable for somebody
who doesn't yet know what it's about.
True, I write them mainly for myself for the moment.


The rules file could need some cleanup - not only removing unneeded
commented lines: Do you have an idea what a CFLAG is? Why do you set it?
From the default... I will need to check the rules file and remove some lines then. This is after all a simple bourne shell script, and no need for things to be compiled (except man pages)


I also had a short look over your buppo script. I don't like that you
hardcode all binaries with absolute pathnames. There is a reason why the
variable PATH exists, and why people use it to use different binaries. I
don't know whether it's against policy, but I'd consider it bad
practice.
Hmm.. perhaps. I also come from the Unix world and there it is also considered a good thing to write the paths like this. Makes it easier to change perhaps. I will consider removing the absolute paths, and trust the PATH instead.


I have no idea about the usefulness of the script, and no intention to
sponsor its upload, be it useful or not. I just wanted to give you some
feedback.
No problems... To be honest, me neither. But I am sure having fun... :) and learning a lot
I really appreciated the comments though

Regards, Frank

Cheers

bengt



Reply to: