On Tue, Jun 7, 2011 at 1:56 AM, gregor herrmann <email@example.com>
On Tue, 07 Jun 2011 01:14:52 +1000, Ingy dot Net wrote:AFAICS, you can't; TTBOMK M::I is copyrighted
> > I suspect you did not write the code below the inc/ subdir, right?
> Funny you should ask. Much of it, yes. I am the original creator of
> Module::Install. But that doesn't matter in principle. It might only matter
> in that I can help change the policy such that using Module::Install does
> not impose any copyright complications on its users. How do I make that so
> for Debian?
2002-2011, Adam Kennedy <firstname.lastname@example.org>
2002-2011, Audrey Tang <email@example.com>
2002-2011, Brian Ingerson <firstname.lastname@example.org>
so we have to include these three lines in debian/copyright for each
package which includes (parts of) M::I in inc/.
What might help (not M::I related) -- as already mentioned by
Dominique -- is to extend the META spec to include more detailed
copyright/license information about all files in a distribution, that
can be used when creating a draft of debian/copyright.
> My primary aim here is to make it natural for CPAN authors to see their work
> all the way through to Debian or any other distribution system. I think it
> is stuffed that things are so complicated that a code author can't easily
> get his code into Debian and any other distribution. Then again, I live in
> the future.
Whatever fancy tools we have (on the CPAN or on the Debian side)
won't change the fact that it needs a human DD to actually
check/build and upload the package to the Debian archive.
This is the thing that really gets me. Does Debian really want human time spent on every last bit? This may seem noble but it really doesn't scale.
I'm not saying that you shouldn't strive for perfection, but computers are better at perfection than humans. Humans are better at programming than computers. So why isn't the effort spent in analyzing the code that checks the code, rather than analyzing every package that goes in, which is flawed at so many levels.
Some thoughts from my downstream point of view:
- The actual packaging usually doesn't take long with dh-make-perl
and a sharp eye. Of course dh-make-perl could be improved to save
us from some small manual steps.
- When it takes more time then because there's something "unusual":
+ missing/unclear copyright/license
+ tests needing network access or writing to $HOME or assuming the
existence of .svn or something
+ tests or build system not cleaning up after themselves
+ interactive tests or build systems
+ typos in the POD
- Most third-party debs (be they created automatically or by some
well-meaning upstream people) I've seen so far where not really
ready for upload to the Debian archive; the problem is that Debian
policy changes and there are quite some subtle details that need
Which leads me to the same conclusion I've already mentioned: If CPAN
authors want to get their code into Debian (yeah! I really appreciate
when they care about Debian) the way to go is IMO not them creating
.debs but making sure that their distributions are easily
`- NP: J.J. Cale: Hard Times