-=| Jonathan Yu, Sat, May 08, 2010 at 08:45:30AM -0400 |=- > On Sat, May 8, 2010 at 1:54 AM, Damyan Ivanov <dmn@debian.org> > wrote: > > * M:I code is copied in every dist that uses it. we have already > > suffered by a bug that has spread over several packages. Code > > duplication is bad. > > I think this is fair, and a situation we should work with upstream > module authors to correct. I think this doesn't affect most authors > because they release their packages quite frequently, and still > consider CPAN (and the cpan shell, cpanminus, etc) to be the "de > facto" way of getting Perl modules. I've been trying to convince > upstream and have had some limited success there. > > Moving forward, I don't see too many regressions in Module::Install > being problematic, but we can always clean inc/Module/Install.pm and > inc/Module/Install/* before installation, and engage author mode to > recreate those things. But I don't know if M::I is actually designed > to always be backward compatible or not. IIRC, the reson to copy M::I in the dist is exactly to avoid maintaining compatibility. (and perhaps save the hassle of installing M::I off CPAN, if it is a hassle) Note I am greatly biased being a heavy Debian user. Additionaly, cleaning before building is not enough. Since inc/ will be present in the .orig.tar.gz, it must be also covered by debian/copyright. The only way to avoid that is to repackage (hundreds of packages :/ ). > > * the code that is copied in the distribution lacks any > > copyright/licensing information. We have to *guess*, which is never > > good; authors may have put their work inder inc/ too. > > I think it applies more to work put under inc/Module/Install; ie, M::I > plugins. Otherwise the information on the copyright.pod page that I > maintain seems to cover most things (and where they don't, people > should feel free to add more!) copyright.pod is indeed a useful workaround. > I don't think this message is overly emotional, you make some cogent > arguments [...] Hopefuly. > In summary: > > I will try to refine these points down and add them to the wishlist. Thanks a lot! > I think the second part is definitely a problem and will be > acknowledged and fixed by Module::Install; the first part shouldn't > be an issue if M::I maintainers can be perfect and totally avoid > regressions... This is hard, but debhelper's way of making incompatible changes can always be used.
Attachment:
signature.asc
Description: Digital signature