Hi Jeremy et al., > It might be a bit late to try to change the source packaging for > all of that.
Oh, I don't know it's ever to late to improve something :) Let me play devil's advocate for a second… Whilst I would agree that uploading a package containing all the existing ones for an addition might potentially be wasteful of mirror bandwidth, rsync & friends would surely be clever enough to notice the the existing tarballs were somewhat similar… Moreover, human time and attention is orders of magnitude more costly than bandwidth and, for example, a packaging bug in any individual package is likely to be simply a bug in all them, and thus would require tedious and error-prone duplication of effort to address across 50-odd packages. Perhaps you have already encountered a sampling of that with the handling these 31 ITPs, or even with quotidien tasks like updating Standards-Version of the existing packages. Providing cross-source scripts to automate such things, whilst obviously possible, regrettably makes poor trade-offs IMHO in terms of maintainability and unnecessarily increases the "bus factor" [0] of the packaging, discouraging contributions. And lastly, this is before we consider the aesthetic implications on the source package namespace. (ie. it's ugly as hell.) Please re-consider? :) [0] https://en.wikipedia.org/wiki/Bus_factor Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
