Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
On Wed, 02 Jan 2008 00:58:12 -0200, Martín Ferrari wrote: On Jan 2, 2008 12:28 AM, Russ Allbery [EMAIL PROTECTED] wrote: This is a Policy proposal that's sat in the Policy bug queue with wording and seconds for quite some time. I'd like to resurrect it and resolve it one way or the other. I think the proposal is a good technical solution to the problem: I really want to still be able to apt-get install libbusiness-onlinepayment-bankofamerica-perl, I don't need to think twice to find it. Count me in -- I appreciate the simple mapping of Foo::Bar to libfoo-bar-perl, too. But, is this really a problem? I don't completely grasp the benefit of using reduced names for libraries. Also, there is the problem of assigning good names. Ack. But I don't oppose to the policy change, as long as the fancy names are optional and the real names are required to be in a Provides field (and that's the way I read the proposal). Call me a consistency freak :) Call me more conservative than I'd like to be :) Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Dire Straits: Money For Nothing signature.asc Description: Digital signature
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
Packages which contain perl modules should provide virtual packages that correspond to the primary module or modules in the package. The naming convention is that for module 'Foo::Bar', the package should provide 'libfoo-bar-perl'. This may be used as the package's name if the result is not too long and cumbersome. Or the package's name may be an abbreviated version, and the longer name put in the Provides field. I dont see a benefit in this at all. It just adds confusion for the sake of short package names. Especially as you shouldnt (build)-depend on virtual packages, so those would need to use the shorter names too. Having the direct x::y is libx-y-perl is IMO more important than less to type in. -- bye Joerg http://meta.wikimedia.org/wiki/How_to_win_an_argument pgpk9QaQBRbqZ.pgp Description: PGP signature
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
Russ Allbery wrote: This is a Policy proposal that's sat in the Policy bug queue with wording and seconds for quite some time. I'd like to resurrect it and resolve it one way or the other. There's some room for clarification here. I think it is apparent from comments given in 2001 the that the policy wish-bug under debate concerns the _binary_ package name, and not the _source_ package name. The Debian policy however isn't entirely clear on whether it intends to mandate the source or binary package name or both. Let me repeat its current text: | 4.2 Module Package Names | | Perl module packages should be named for the primary module provided. | The naming convention for module Foo::Bar is libfoo-bar-perl. Packages | which include multiple modules may additionally include provides for | those modules using the same convention. I think that from the final sentence it can be inferred that it primarily intends to mandate the _binary_ package name. So while we're discussing the binary package naming, maybe we can decide whether the mandate should be extended to the _source_ package name as well while we're at it, and clarify the Perl policy to explicitly state whether or not the source package name is covered by the policy's recommendation. I know the question of source package naming for Perl modules has been discussed on debian-perl before, but that was just about the Debian Perl Group's own conventions, not about the global Perl policy. The Perl Group can still maintain stricter conventions even if the Perl policy gets relaxed with regard to source package names. As far as _binary_ package names are concerned, I think they should follow an automatable pattern (i.e. the Perl policy's recommendation for binary package names should stay as it is). Long package names are a non-issue given Bash completion and package managers with incremental search features. As for _source_ package names, I think they should be free-form. signature.asc Description: This is a digitally signed message part.
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
On Wed, 02 Jan 2008, Julian Mehnle wrote: I think that from the final sentence it can be inferred that it primarily intends to mandate the _binary_ package name. So while we're discussing the binary package naming, maybe we can decide whether the mandate should be extended to the _source_ package name as well while we're at it, and clarify the Perl policy to explicitly state whether or not the source package name is covered by the policy's recommendation. Unless there's a compelling reason to the contrary, a source package should in general build at least one binary package of the same name. This is definetly the case when the source package only builds one binary package. The reasons why you want to do this is because everyone knows what the binary package name is, but it's sometimes difficult to map to a source package, and it prevents the insanity of Source: foo building Binary: bar, and Source: bar buildling Binary: foo. (Yes, there is at least one set of packages in the archive that does this.) Don Armstrong -- If you wish to strive for peace of soul, then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
Don Armstrong wrote: On Wed, 02 Jan 2008, Julian Mehnle wrote: I think that from the final sentence it can be inferred that it primarily intends to mandate the _binary_ package name. So while we're discussing the binary package naming, maybe we can decide whether the mandate should be extended to the _source_ package name as well while we're at it, and clarify the Perl policy to explicitly state whether or not the source package name is covered by the policy's recommendation. Unless there's a compelling reason to the contrary, a source package should in general build at least one binary package of the same name. This is definetly the case when the source package only builds one binary package. According to a simple survey of the packages in Lenny/amd64 (main, contrib, non-free), 2365 of the 11757 source packages (20%!) have no binary package of the same name. 814 of these (7% of all) have only a single binary package. Wanna mass-file bugs? Or maybe the reason doesn't have to be all that compelling. signature.asc Description: This is a digitally signed message part.
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
On Wed, Jan 02, 2008 at 03:46:02PM -0800, Don Armstrong wrote: On Wed, 02 Jan 2008, Julian Mehnle wrote: I think that from the final sentence it can be inferred that it primarily intends to mandate the _binary_ package name. So while we're discussing the binary package naming, maybe we can decide whether the mandate should be extended to the _source_ package name as well while we're at it, and clarify the Perl policy to explicitly state whether or not the source package name is covered by the policy's recommendation. Unless there's a compelling reason to the contrary, a source package should in general build at least one binary package of the same name. This is definetly the case when the source package only builds one binary package. Not that this is applicable to perl packages, but one very common reason for this to not be the case is that the package is a library... In that case, it's beneficial to have continuity of the source package name whereas the binary package name will change periodically. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
On Wed, 02 Jan 2008, Steve Langasek wrote: On Wed, Jan 02, 2008 at 03:46:02PM -0800, Don Armstrong wrote: Unless there's a compelling reason to the contrary, a source package should in general build at least one binary package of the same name. This is definetly the case when the source package only builds one binary package. Not that this is applicable to perl packages, but one very common reason for this to not be the case is that the package is a library... In that case, it's beneficial to have continuity of the source package name whereas the binary package name will change periodically. Right; that's exactly the major compelling reason that I was thinking about when I wrote the above. Don Armstrong -- There is no such thing as social gambling. Either you are there to cut the other bloke's heart out and eat it--or you're a sucker. If you don't like this choice--don't gamble. -- Robert Heinlein _Time Enough For Love_ p250 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
On Thu, 03 Jan 2008, Julian Mehnle wrote: According to a simple survey of the packages in Lenny/amd64 (main, contrib, non-free), 2365 of the 11757 source packages (20%!) have no binary package of the same name. 814 of these (7% of all) have only a single binary package. Wanna mass-file bugs? No, because changing the source package name is worse than having a stupid source package name. [The complications that it makes for bug tracking is the major reason why changing source package names should not be done unless required.] Or maybe the reason doesn't have to be all that compelling. The reason should be compelling. While it's unfortunate that stupid source package names have been chosen on initial uploads in the past, I'm more concerned about the choice of source package names going forward. Don Armstrong -- He no longer wished to be dead. At the same time, it cannot be said that he was glad to be alive. But at least he did not resent it. He was alive, and the stubbornness of this fact had little by little begun to fascinate him -- as if he had managed to outlive himself, as if he were somehow living a posthumous life. -- Paul Auster _City of Glass_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
This is a Policy proposal that's sat in the Policy bug queue with wording and seconds for quite some time. I'd like to resurrect it and resolve it one way or the other. Since this is a change to the Perl packaging policy, specifically for Perl modules, I'm cc'ing the debian-perl list, as the most likely available set of experts in this area. I'm quoting the full original proposal to keep people from having to go to bugs.debian.org for it. My reading of the bug log was that this proposal previously reached consensus, but applying six-year-old changes based on a previous consensus is usually a bad idea. I'm personally indifferent. (In many cases, I'm not sure what the useful abbreviation for the package name would be, but that would be up to the maintainer.) Joey Hess [EMAIL PROTECTED] writes: Rationalle: Perl policy currently dictates that a perl module package have a name of the form lib-foo-bar-perl, where foo-bar maps to Foo:Bar in the perl module name. This is resulting in a lot of very large and awkward package names -- the worst ofender so far is the longest named package in the entire distribution: libbusiness-onlinepayment-bankofamerica-perl There are a lot of other very long package names that result from this foolish consistency, and indeed perl module packages make up 1/5th of all the packages with names in excess of 25 characters. Reducing the size of these packages names will thus have a large impact on the length of Debian's package names in general; this in turn has many ramificatons large and small everywhere users deal with or are exposed to package names. (Typing in libbusiness-onlinepayment-bankofamerica-perl is not fun. Neither is seeing it truncated to 20 characters in dpkg -l.) At the same time, this consistency of package names can indeed be very useful, when things are being automated, and we shouldn't lose that benefit with foolish inconsistency. Proposal: Replace section 3.2 of the perl sub-policy included with Debian policy with the following text: Packages which contain perl modules should provide virtual packages that correspond to the primary module or modules in the package. The naming convention is that for module 'Foo::Bar', the package should provide 'libfoo-bar-perl'. This may be used as the package's name if the result is not too long and cumbersome. Or the package's name may be an abbreviated version, and the longer name put in the Provides field. Also, although they are not currently part of the formal policy, there are conventions to use similar naming for java (and maybe python) module packages, and if this proposal is passed, those informal policies should be updated to work the same way. Transition: There is no need for a transition plan for this proposal. It allows existing packages to remain unchanged, while new packages use shorter names as desired. Existing packages can be renamed to shorter names at their maintainers' discretion, though if they do, they'll have to watch out for versioned dependancies (rare; very little depends on perl module packages at all). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
Hi, On Jan 2, 2008 12:28 AM, Russ Allbery [EMAIL PROTECTED] wrote: This is a Policy proposal that's sat in the Policy bug queue with wording and seconds for quite some time. I'd like to resurrect it and resolve it one way or the other. I think the proposal is a good technical solution to the problem: I really want to still be able to apt-get install libbusiness-onlinepayment-bankofamerica-perl, I don't need to think twice to find it. But, is this really a problem? I don't completely grasp the benefit of using reduced names for libraries. Also, there is the problem of assigning good names. Perl modules usually don't have fancy names, saving a couple of distributions. For XS wrappers of C libraries, it could just use the name of the C library plus -perl, but what about the rest of CPAN? And I find the lack of a lib prefix (like the python people do) ugly. Call me a consistency freak :) -- Martín Ferrari
