On 07/10/2013 10:30 PM, Stuart Prescott wrote: > Thomas Goirand wrote: >> On 07/08/2013 10:10 PM, Scott Kitterman wrote: >>> There is no policy on this either way, so there's no "mistake". >> >> Well, the mistake is precisely to have no rule, IMO. > > Rules for packaging things are normally there to solve problems of > interoperability and to assist QA efforts. Which of these is it going to > help? > >> Never the less, I think we should collectively decide what to do, rather >> than continuing the mess, with everyone having its own rule. > > What mess? If there is a perceived mess, why is that a problem in any case? > How does it help to make a new rule? Who does it help? What problem does > this solve? Why is any intellectual energy being spent on this at all?
Oh, I need this pyX package... Let's download it. # apt-get source pyX Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to find a source package for pyX shit, let's try again... # apt-get source python-X Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to find a source package for python-X grr... # apt-get source X Reading package lists... Done Building dependency tree Reading state information... Done [...] And then, finally, it's called "migrate" instead of "sqlalchemy-migrate" like upstream called it... :) (this never happened to me with python-migrate, though that's a good example of a IMO badly named source package) And that's just an example on what can go wrong and be really annoying. It's even more annoying when you are trying to do a "git svn clone" which takes forever. Sure, we can continue and have a "free for all" thing, though knowing what the others do, and try to do the same so we *at least try* to have a bit of consistency, can't hurt. > It looks exceedingly like a rule for the sake of having a rule. It will be > an exceedingly complicated rule in that it will have to cover python > modules, python applications and other libraries that offer python bindings > all separately. It will have to be accompanied an explanation of why so many > packages don't follow it because they were uploaded prior to the rule > existing. Basically... unless we are going to force every existing source > package to change name to comply with this rule there is no point in having > it (and no-one has advocated renaming source packages as is useless work for > everyone). Ok, so let's not use the word "rule" but call it "guide-line", and for future packages only (I have *never* proposed to change already uploaded packages). Do you feel more comfortable now? :) Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ddbbdb.6070...@debian.org
