-=| Nicolas Mendoza, 30.03.2016 18:49:53 +0200 |=- > On 30. mars 2016 18:36, gregor herrmann wrote: > >tl;dr: Let's make dh-make-perl source format '3.0 (native)'. > > > >Currently dh-make-perl is a non-native package; its d/watch file > >points to https://alioth.debian.org/frs/?group_id=30274 ; > >additionally it's also on the CPAN: > >https://metacpan.org/release/DhMakePerl > > > >In practice, the git repo is the authoritative source; in order to > >create a tarball, `make orig' has to be invoked, and at release time > >this tarball is then uploaded to Alioth and the CPAN. - This has > >several drawbacks and problems: > > > >- It's quite some work to make a relase; > >- which is almost exclusively done by Damyan (thanks!), esp. for > > reasons of CPAN permissions; > >- the tarballs on Alioth pretend that this is the upstream for the > > package while in reality it's just an afterthought; and I can't > > image that anybody would download the tarball from there when it's > > in the archive (or on snapshots.d.o) anyway; > >- DhMakePerl can't be installed from the CPAN because of some > > Debian-specific modules and tools [0]; also there are 2 changelogs; > >- developping is tedious as each build needs a new tarball first. > > > > > >dh-make-perl was a native package until 0.66-1 / 19 Apr 2010; but I > >don't remember why we changed it 6 years ago … The reason was, AFAIR, to get it on CPAN. It was an experiment to see how useful that would be. I am not sure of the results, since I have always run dh-make-perl from the development tree. Success stories, anyone? > >I think switching back to a native package makes sense, saves work, > >stops pretentions and assumptions which were never true, and also > >seems "logically correct". Therefore I tentatively propose to change > >the source format, and actually also to remove the tarballs from > >Alioth (although they don't hurt as historical artifacts from the > >non-native era), and to remove DhMakePerl from the CPAN (move it to > >the BackPAN or however this all works). > > > I have been wishing the opposite, make the CPAN one actually be relevant and > be useful regardless of Debian version. How is that possible? dh-make-perl always depended on things which are natural part of a Debian system's infrastructure. Transferring this dependency to CPAN would mean getting APT on CPAN -- something I see no use of (and have no idea if it is feasible at all). > I have wished to be able to simply install the cpan version on an > old debian system to get that working, but ended up stuck with the > dh-make-perl that came with that system. This is normal for any Debian package. If you need the latest and greatest, install Debian/unstable and use dh-make-perl from there. VMs are cheap these days. You don't run dh-make-perl on your production server anyway, right? The packages the latest dh-make-perl produces should be suitable for older Debian releases. And if not, then there's some work to do like preparing updated dependency packages, but this is regardless to whether you use your old Debian's dh-make-perl or the Git snapshot. > Perhaps > dh-make-perl DhMakePerl should just work and do the correct thing. How would you feel if that worked by upgrading your package manager? (Context: dh-make-perl in Git requires apt-file/apt from Debian/unstable). For me, the main point of existence of dh-make-perl is to ease the job of the lovely team that makes packages for Perl libraries available to Debian users. It provides a base, from which the package maintainer can take over and produce a package suitable for the Debian archive. It is not the Debian incarnation of 'cpan install', even if it often can be used as such if one is in a hurry. I wonder, if DhMkePerl is removed from CPAN, maybe someone interested in making it more usable to CPAN users can fork it and everyone will be happy? -- dam
Attachment:
signature.asc
Description: Digital signature