Re: Need experienced perl module maintainer for a second pair of eyes on my package
Marc Haber (email@example.com) wrote:
> I really appreciate the comments, thanks.
> > - Why is there an empty /usr/lib/perl5 directory in your package?
> Because the Makefile generated by MakeMaker makes that directory on
> install. I now delete it after installation. Any idea how to make
> MakeMaker stop generating that directory?
I noticed you're still doing a 'pure_install'. Try doing an 'install' and see whether
that fixes this problem. I never had to remove directories manually.
> > - The debian/rules is not in accordance with the Perl Policy, e.g
> > you shouldn't define PERL,
> Fixed. I don't exactly understand why, though.
In cases like this I simply follow policy. You could alwasy ask on debian-perl.
> > you define
> > INSTALLDIRS=perl5 but you don't use it, etc.
> That is not a policy violation ;)
> Fixed anyway.
I know, but I like things as clean as possible.
> > I would suggest to
> > take a look at one of my packages for ideas.
> the rules file from libdbd-ram-perl doesn't look _that_ different ;)
Again, I know, but I thought an example couldn't hurt. And maybe you noticed
some other differences.
I noticed some other things:
- The binary-arch target has a build dependency. Why? Your package is
arch independent, so it shouldn't do anything for arch specific.
- Why did you comment out dh_md5sums?
- You have the order of dh_installdeb and dh_perl reversed from mine. Any
particular reason? I'm not sure it would make a difference, but it could.
- Why do you have a 'dh_clean -k'? I'm not sure, but removing the '-k' can
also make it possible to remove the line 'rm -f debian/files'.
- Why do you 'manually' remove all the different stamps? You don't use any
- Why the 'rm -f Makefile.old'?
- You should install the upstream Changes via 'dh_installchangelogs' and not
> >By the way, is this a Debian only package? I noticed you had the debian
> >directory in the .orig.tar.gz file and als a diff file.
> This is currently a Debian only package, but I want to reserve the
> possibility to publish the module outside of Debian. So I treat it as
> a non-debian-native package where upstream has a Debian tree, as well.
> The new version has the current debian directory in the "upstream"
> tarball which makes the diff pretty small. If new Debian versions
> become necessary without bumping the upstream version number, changes
> to the debian directory will go into the diff, leaving the "upstream"
> tarball intact.
Ok, I see.
Ardo van Rangelrooij
home email: firstname.lastname@example.org
home page: http://people.debian.org/~ardo
GnuPG fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9