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#172436: [PROPOSAL] web browser url viewing
On Tue, Jan 01, 2008 at 09:08:30PM -0800, Russ Allbery wrote: Here is a patch based heavily on Joey's original patch that describes that. This patch (similar to Joey's) doesn't include the URL canonicalization requirements of the secure BROWSER specification. They don't seem obviously necessary to me and are complex and would add a lot of additional wording to explain how to canonicalize URLs. Comments? Seconds? Solely for being better specified, I think either this or the Compatible definition is preferable to the ESR original. I never use BROWSER myself, so I'm hesitant to weigh in on the other aspects. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#152955: Turning a small knob into a huge wand!
regards Nothing c'n B better than our pharmas! http://dobongworld.com From the Coast of Coromandel, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#152955: Make your holidays happier with this new EDPILLZ_ENHANCEMENT formula!
regards Nothing c'n B better than our pharmas! http://dobongworld.com And a pound of Rice, and a Cranberry Tart, -- 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
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 pgpclkfGXmapW.pgp Description: PGP signature
Bug#250202: debian/README.source file for packages with non-trivial source
Hi Russ, First, thanks for your great work on this bug. On Tue, Jan 01, 2008 at 10:54:06PM -0800, Russ Allbery wrote: This is the last Policy bug I had tagged as wording. It started with a proposal for a README.source file documenting how to do things with a package that uses a non-trivial source format, and then expanded into standardizing debian/rules targets for doing various things. Having reviewed the entire bug thread, I think there are a few misconceptions and a few different cases mingled together, so I'm going to attempt a summary. The original concern was being able to unpack a Debian source package and immediately start patching it, with a goal of creating a modified source package (for local modifications, security fixes, RC bug fixes, or what have you). I think that sums it up quite right, yeah :) Among the source package formats in Debian, I know of two possible situations: [...summary of patch systems snipped...] Now, I think that everyone (possibly except Marco) agrees with the basic idea of providing a README.source file explaining how to deal with a package that has a non-trivial source layout. In particular, I think someone needs to know how to do all of the following: 1. Generate the fully patched sources, the sources in the state in which they'll be built, so that one can check to see if problems have been patched, look at the source, and so forth. 2. Add a new patch to the build process (including any special techniques to use to generate the patch if there's an easier tool than recursive diff from an unmodified package and the like). 3. Remove an existing patch from the build process. 4. Ideally, explain how to upgrade the package to a new upstream version, although this should probably be optional. However, when we get into standardizing targets, this gets a lot murkier. I think the discussion above makes it clear that the only thing that we can really address with a target is point 1 above. For all of the systems, in the general case of modifications that overlap with existing patches, I don't think we can provide targets that do 2. 3 and 4 are obviously outside what a target can do. Yes, that seems correct. I hadn't thought of that problem, actually, but now that you mention it, I don't think there are ways of making that easy. In short, as you show, sticking to just adding one or more optional targets to debian/rules isn't going to cut it. Accordingly, I think moving forward with specifying a README.source file that explains the above three or four points is something we can reach consensus on. I'm not as sure about standardizing a target for 1 (setup, unpack, and patch are all currently in use), but I suppose that we could standardize on patched. This does raise insta-buggy issues since existing packages don't provide that target. However, I don't think it's going to work to say that after running some target, people should be able to make modifications and run dpkg-buildpackage and expect to have that work. In each case, it looks like there are cases where that isn't going to work, and I don't think it's viable to say that those patch systems can't be used. Makes sense. So, finally, I propose the following patch: --- orig/policy.sgml +++ mod/policy.sgml @@ -1926,6 +1926,19 @@ possible is a good idea. /p /item + + tagttpatched/tt (optional)/tag + item + p + This target performs whatever additional actions are + required to make the source ready for editing (unpacking + additional upstream archives, applying patches, etc.). + It is recommended to be implemented for any package where + ttdpkg-source -x/tt does not result in source ready + for additional modification. See + ref id=readmesource. + /p + /item /taglist p @@ -2076,6 +2089,50 @@ the file to the list in filedebian/files/file./p /sect + sect + headingSource package handling: + filedebian/README.source/file/heading + + p + If running prgndpkg-source -x/prgn on a source package + doesn't produce the source of the package, ready for editing, + and allow one to make changes and run + prngdpkg-buildpackage/prgn to produce a modified package ---^ Seems you've missed a there. + without taking any additional steps, creating a + filedebian/README.source/file documentation file is + recommended. This file should explain how to do all of the + following: + enumlist + itemGenerate the fully patched source, in a form ready for + editing, that would be built to create Debian + packages. Doing this with a ttpatched/tt target in + filedebian/rules/file is
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.
www.dermatology-online.com.ar
Please see this site in Subject
Bug#122038: annihilate patchy
Hi, wouldn't you have extroardinary member http://www.slushfuns.com Lyman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#172436: lame persuasive
Hello, would you expect extroardinary cock http://www.rapkocrats.com Lacy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#122038: lebanon execrate
would you like larger slong http://www.Reelhotsi.com Esperanza -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#152955: knew retrogression
would you have big member http://www.Foredroons.com Willis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250202: debian/README.source file for packages with non-trivial source
Colin Watson [EMAIL PROTECTED] writes: On Tue, Jan 01, 2008 at 10:54:06PM -0800, Russ Allbery wrote: Accordingly, I think moving forward with specifying a README.source file that explains the above three or four points is something we can reach consensus on. I'm not as sure about standardizing a target for 1 (setup, unpack, and patch are all currently in use), but I suppose that we could standardize on patched. This does raise insta-buggy issues since existing packages don't provide that target. This is only a mild objection (I think this is too valuable a change for me to want to stand in its way), but I am curious why you picked a target name which AFAIK isn't used by more than a handful of existing packages, rather than one of the ones which are common? In the latter case, at least we'd have a head-start on implementation. (If patched is in use by one of the major patch systems today and I just forgot about it, please let me know.) Part of the original thread was picking something that currently wasn't used so that we could be assured that we weren't changing the semantics of something already out there. However, we could standardize patch instead of patched, which will pick up quilt and dpatch at least. It would cause problems if one of the other systems used patch to mean something different, but I'm not aware of one that does. dbs doesn't appear to. -- 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#250202: debian/README.source file for packages with non-trivial source
Wouter Verhelst [EMAIL PROTECTED] writes: Hi Russ, First, thanks for your great work on this bug. Thanks! It feels good to go back and resolve long-standing issues. + prngdpkg-buildpackage/prgn to produce a modified package ---^ Seems you've missed a there. Thanks, fixed in my repository. -- 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
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]
Re: 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
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, 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#458824: better specification for when rpath is permitted is needed
Package: debian-policy Version: 3.7.3.0 Severity: wishlist While analyzing http://bugs.debian.org/456318 I noticed that there's nothing in Policy about when binaries are allowed to use rpath. The question raised in that bug is whether games are allowed by FHS to put their shared libraries in /usr/lib/games instead of /usr/lib. But more generally, we really need a specification of use of rpath that: * Says that binaries must not put standard paths such as /usr/lib, /usr/local/lib, and so forth in their rpath since this overrides the ordering possibly configured by the local system administrator. The system administrator may want /opt/lib take priority over all other library directories or something (and there are also multilib concerns). * Mentions setting rpath to point to a private directory for a package. Take a clear stance on whether this is allowed for multiple cooperating packages or only within a single package, since this is frequently debated and either it's allowed or it isn't. * Takes some stance on the /usr/lib/games question and similar questions about adding rpath pointing to other system directories. I'd love it if someone could take a shot at proposed wording for this since I have a lot on my plate at the moment. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
