On Tue, 30 Jun 2015 17:35:46 -0400 Sandro Tosi <morph@debian.org> wrote: > at work we use it, so why not package it properly instead of keeping a > private deb? If I had upstream code which needed this support, I'd just embed it into the project and update the copyright instead of having a package for 18 lines in the first place. It's very generic and trivial python, it just doesn't seem worth the overhead of adding the dependency to setup.py and pydist-overrides, ensuring that the package gets backported to jessie etc. likely to find that a bit down the road we'd need to extend it a little bit more which would be a lot easier to do with the code not being a package. I wouldn't have thought it would be worthwhile to put through NEW, to be honest. In fact, even if the package existed in Debian, I'd expect other projects to simply implement the functionality inside a larger class instead of doing an import anyway. It's not as if there's anything truly innovative in the code which would be identifiable as an embedded copy. It's a (trivial) snippet, albeit interesting. However, I've used larger code samples from stackoverflow as the basis for changes to fix bugs before now. I wouldn't be surprised to find something this small in the documentation of a larger package (like django). Embedding is a problem when the code is of an appreciable size or complexity - this code doesn't qualify on either count. Isn't there a library into which this can be included instead of wasting mirror space on the whole packaging overhead? (Listing in Packages.gz, Contents.gz, mirrors, packages.debian.org and /var/cache/apt/ etc.) Or just add it to a utils.py in the project which uses it? -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpHisJcDYuPD.pgp
Description: OpenPGP digital signature