Bug#474529: Perl policy vs. the search order for .1{,p} manpages
reassign 474529 libmodule-corelist-perl 2.15-1 retitle 474529 should divert corelist.1.gz too thanks On Wed, Aug 06, 2008 at 05:12:53PM +0300, Niko Tyni wrote: On Wed, Aug 06, 2008 at 06:37:44PM +1000, Brendan O'Dea wrote: My thoughts exactly. Although this does suggest that perhaps policy should be amended to use .1 or .1p for both core and vendor. Yes, currently shipping corelist.1.gz in libmodule-corelist-perl would be a violation of the Perl policy. ... but I now realize we don't actually need that. Just diverting corelist.1.gz away and shipping corelist.1p.gz should work fine. I suppose #474529 should be reassigned to libmodule-corelist-perl then, and another bug cloned/submitted against the policy. I'll do that unless somebody protests. As there doesn't seem to be a real need for a policy change, I'm skipping that part at least for now. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474529: Perl policy vs. the search order for .1{,p} manpages
On Wed, Aug 06, 2008 at 08:57:34AM +0300, Niko Tyni wrote: On Wed, Aug 06, 2008 at 10:20:54AM +1000, Brendan O'Dea wrote: Is this not going to cause some large measure of grief when either of perl or libmodule-corelist-perl upgrades? I don't see why. The script is handled with dpkg-divert in the libmodule-corelist-perl maintainer scripts, the package doesn't blindly Replace: perl. Just like the module case, we assume that nobody wants to use the older script if a newer one is installed. I'd contend that you should simply divert the manual page in the same way. It's almost always wrong to handle manual pages differently from binaries in maintainer scripts - if you divert foo to foo.real, you should also divert foo.1.gz to foo.real.1.gz. (Similarly for alternatives.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474529: Perl policy vs. the search order for .1{,p} manpages
On Wed, Aug 6, 2008 at 6:34 PM, Colin Watson [EMAIL PROTECTED] wrote: I'd contend that you should simply divert the manual page in the same way. It's almost always wrong to handle manual pages differently from binaries in maintainer scripts - if you divert foo to foo.real, you should also divert foo.1.gz to foo.real.1.gz. (Similarly for alternatives.) My thoughts exactly. Although this does suggest that perhaps policy should be amended to use .1 or .1p for both core and vendor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474529: Perl policy vs. the search order for .1{,p} manpages
On Wed, Aug 06, 2008 at 10:20:54AM +1000, Brendan O'Dea wrote: The reason that modules manual pages have distinct extensions is to prevent filename collisions between CORE and vendo, since they share the same manual directory. man-db fortunately has a mechanism to select the correct page for a section: man Foo, or man 3 Foo will present the first of 3pm or 3perl which it finds. Sadly, the shell has no such selection mechanism, so even if you do use different extensions for section 1 pages, you will still get a collision on the script. http://packages.debian.org/search?suite=sidarch=anysearchon=contentskeywords=%2Fusr%2Fbin%2Fcorelist Is this not going to cause some large measure of grief when either of perl or libmodule-corelist-perl upgrades? I don't see why. The script is handled with dpkg-divert in the libmodule-corelist-perl maintainer scripts, the package doesn't blindly Replace: perl. Just like the module case, we assume that nobody wants to use the older script if a newer one is installed. The problem in #474529 is that man-db prefers corelist.1 from the core over the newer corelist.1p from libmodule-corelist-perl when no section is specified. So the user gets a wrong manual page by default. This can be fixed either by changing the core extension to something that can be moved down on the man-db search list (like .1perl) or by moving the module extension (.1p) up on the search list, which would place it first. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474529: Perl policy vs. the search order for .1{,p} manpages
On Wed, Aug 6, 2008 at 4:34 AM, Niko Tyni [EMAIL PROTECTED] wrote: while Brendan hasn't found the time to comment on this, I think moving .1p up on the search list would be the best thing to do for lenny at least. Would you still be willing to do that? The reason that modules manual pages have distinct extensions is to prevent filename collisions between CORE and vendo, since they share the same manual directory. man-db fortunately has a mechanism to select the correct page for a section: man Foo, or man 3 Foo will present the first of 3pm or 3perl which it finds. Sadly, the shell has no such selection mechanism, so even if you do use different extensions for section 1 pages, you will still get a collision on the script. http://packages.debian.org/search?suite=sidarch=anysearchon=contentskeywords=%2Fusr%2Fbin%2Fcorelist Is this not going to cause some large measure of grief when either of perl or libmodule-corelist-perl upgrades? If a newer pod2man is going to be in a separate package (see the debian-perl thread), this is going to become a bit more important than just the libmodule-corelist-perl issue. So this particular issue needs to be addressed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474529: Perl policy vs. the search order for .1{,p} manpages
On Wed, Aug 06, 2008 at 09:34:52AM +0100, Colin Watson wrote: I'd contend that you should simply divert the manual page in the same way. It's almost always wrong to handle manual pages differently from binaries in maintainer scripts - if you divert foo to foo.real, you should also divert foo.1.gz to foo.real.1.gz. (Similarly for alternatives.) Heh, quoting yourself in March: Diverting corelist.1.gz would definitely be wrong. http://lists.debian.org/debian-perl/2008/03/msg00088.html But I see I failed to mention back then that /usr/bin/corelist itself is diverted too. I can see that this makes the difference here. On Wed, Aug 06, 2008 at 06:37:44PM +1000, Brendan O'Dea wrote: My thoughts exactly. Although this does suggest that perhaps policy should be amended to use .1 or .1p for both core and vendor. Yes, currently shipping corelist.1.gz in libmodule-corelist-perl would be a violation of the Perl policy. I suppose #474529 should be reassigned to libmodule-corelist-perl then, and another bug cloned/submitted against the policy. I'll do that unless somebody protests. -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474529: Perl policy vs. the search order for .1{,p} manpages
On Wed, Aug 06, 2008 at 05:12:53PM +0300, Niko Tyni wrote: On Wed, Aug 06, 2008 at 09:34:52AM +0100, Colin Watson wrote: I'd contend that you should simply divert the manual page in the same way. It's almost always wrong to handle manual pages differently from binaries in maintainer scripts - if you divert foo to foo.real, you should also divert foo.1.gz to foo.real.1.gz. (Similarly for alternatives.) Heh, quoting yourself in March: Diverting corelist.1.gz would definitely be wrong. http://lists.debian.org/debian-perl/2008/03/msg00088.html But I see I failed to mention back then that /usr/bin/corelist itself is diverted too. I can see that this makes the difference here. Indeed, I don't think I was aware of that (although I'm not sure how I thought it was handled ...). Sorry for the confusion caused. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474529: Perl policy vs. the search order for .1{,p} manpages
reassign 474529 man-db thanks On Wed, Mar 19, 2008 at 12:15:42PM +, Colin Watson wrote: On Wed, Mar 19, 2008 at 01:51:46PM +0200, Niko Tyni wrote: While manpages for separately packaged modules (.3pm) are preferred over those bundled with the Perl core (.3perl), this is not the case for separately packaged scripts (.1p) vs. bundled ones (.1). This is a real problem with libmodule-corelist-perl and perl 5.10.0: with both installed, 'man corelist' gives the older manual which doesn't document the new '-d' option. Explicitly asking for the newer one with eg. 'man -S 1p corelist' works fine, of course. Why was section 1 chosen in the Perl policy in the first place? Is there a reason why '1perl' wouldn't work? I suggested this in http://lists.debian.org/debian-perl/2001/03/msg8.html but Brendan wasn't keen (see the follow-up). If Brendan wants to revisit this decision in light of this problem, that'd be great; otherwise I'm actually quite happy to put 1p in front of 1 in the search order. Let me know. Hi Colin, while Brendan hasn't found the time to comment on this, I think moving .1p up on the search list would be the best thing to do for lenny at least. Would you still be willing to do that? If a newer pod2man is going to be in a separate package (see the debian-perl thread), this is going to become a bit more important than just the libmodule-corelist-perl issue. Reassigning #474529, but feel free to bounce it back if you like. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
