Re: Inconsistency in source package naming for python modules
Am 10.07.2013 16:30, schrieb Stuart Prescott:
> 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?
energy? maybe. but intellectual?
> 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).
It is good to have a naming schema for binary packages, however it is easy to
get from there to the name of the source package. I think I got some bug
reports to include the upstream source name into the short package description
when it doesn't match the module name, so that it can be found by apt-cache -n
search. But again, no need for a policy here.
Matthias
Reply to: