Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sun, May 06, 2001 at 11:58:56PM +0300, Richard Braakman wrote: Yes, but if I amend the proposal like this, then it needs to be seconded all over again, doesn't it? I don't see why. You need two seconds to go from proposal to amendment. To go from amendment to accepted, you need consensus on the mailing list. This consensus presumably includes the opinions of the original seconders. Achieving consensus is usually going to involve some minor changes to the amendment -- that's the whole point of discussing it. If those changes then invalidate the amendment so that the whole process has to be started over again, then the policy process would be quite heavyweight. I don't think that was the intent. Well, they don't invalidate it, but they change it from the one that the seconders seconded. How do I know their second still stands for the changed proposal, unless I get them to second it again? (It most probably does in this case.) -- Digital Electronic Being Intended for Assassination and Nullification
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Mon, May 07, 2001 at 10:58:19PM +0200, Josip Rodin wrote: Yes, but if I amend the proposal like this, then it needs to be seconded all over again, doesn't it? [...] Well, they don't invalidate it, but they change it from the one that the seconders seconded. How do I know their second still stands for the changed proposal, unless I get them to second it again? (It most probably does in this case.) Seconders have to be expected to keep paying attention to the things they second. If the proposal becomes amended in such a way that they disagree with it, they have to speak up. If they can't be bothered to pay that much attention, they should either not second it in the first, or be prepared to accept that they might lend their support to proposals with which they disagree. Remember, policy is supposed to be a lightweight process. -- G. Branden Robinson | Optimists believe we live in the best of Debian GNU/Linux| all possible worlds. Pessimists are [EMAIL PROTECTED] | afraid the optimists are right. http://www.debian.org/~branden/ | pgpFSyOZokLmP.pgp Description: PGP signature
Processed: Re: Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
Processing commands for [EMAIL PROTECTED]: retitle 66023 [AMENDMENT 06/05/2001] Treat plugins and shared libraries differently Bug#66023: [PROPOSAL] Treat plugins and shared libraries differently Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
retitle 66023 [AMENDMENT 06/05/2001] Treat plugins and shared libraries differently thanks Four developers have seconded this proposal, so according to 3.3 Creating an Amendment of policy-process document, this proposal is an amendment. I'm not sure about the date, the document says [AMENDMENT DD/MM/YYY] ... which 1) lacks one final Y :) and 2) doesn't say if the date is of the day when the proposal acquires two seconds, or the date when one sends the retitling message, or what. On Sun, Apr 29, 2001 at 04:23:56PM +0200, Josip Rodin wrote: I think we should amend the proposal with a note that the plugins aren't exempt from stripping -- this is my oversight. Also, that is a should rule, so if there are exceptions, this won't cause serious bugs. I'm don't know about -fPIC, though, that is a must rule. A footnote would be fine, I suppose. I would prefer to let this rest until the initial amendment is in Policy, since it's not very easy to get seconds and this amendment is already overdue. Besides, hopefully nobody will try to make their plugins unstripped in the meantime. -- Digital Electronic Being Intended for Assassination and Nullification
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sun, May 06, 2001 at 01:22:50PM +0200, Josip Rodin wrote: I would prefer to let this rest until the initial amendment is in Policy, since it's not very easy to get seconds and this amendment is already overdue. Surely it's possible to change a proposed amendment before it is accepted? That's the whole point of discussing it. Seconding is supposed to mean I think this proposal is worth considering. If it means I think this proposal is perfect as written, then our policy process is no longer lightweight. Besides, hopefully nobody will try to make their plugins unstripped in the meantime. There are already plugins that are not compiled with -fPIC, though. (megahal and wine have some on my system.) Richard Braakman
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sun, May 06, 2001 at 05:41:44PM +0300, Richard Braakman wrote: On Sun, May 06, 2001 at 01:22:50PM +0200, Josip Rodin wrote: I would prefer to let this rest until the initial amendment is in Policy, since it's not very easy to get seconds and this amendment is already overdue. Surely it's possible to change a proposed amendment before it is accepted? That's the whole point of discussing it. Seconding is supposed to mean I think this proposal is worth considering. If it means I think this proposal is perfect as written, then our policy process is no longer lightweight. Yes, but if I amend the proposal like this, then it needs to be seconded all over again, doesn't it? I am not convinced that it would be possible to get sponsors again in a timely manner. I'd rather if we don't drag this any more. Plugins have existed for years, this bug was filed almost a year ago, and the patch is almost as old. If this becomes an ammendment now, the next version of Policy will contain it (due to be released within a month, I most sincerely hope). It won't be perfect, but it will be fairly acceptable. I will reopen the bug (or file a new one) and then we can go through the discussion and requesting for sponsors again. Besides, hopefully nobody will try to make their plugins unstripped in the meantime. There are already plugins that are not compiled with -fPIC, though. (megahal and wine have some on my system.) Hmm, but is there a reason against that, are we certain that those plugins must be relocatable? -- Digital Electronic Being Intended for Assassination and Nullification
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sun, May 06, 2001 at 04:53:12PM +0200, Josip Rodin wrote: Yes, but if I amend the proposal like this, then it needs to be seconded all over again, doesn't it? I don't see why. You need two seconds to go from proposal to amendment. To go from amendment to accepted, you need consensus on the mailing list. This consensus presumably includes the opinions of the original seconders. Achieving consensus is usually going to involve some minor changes to the amendment -- that's the whole point of discussing it. If those changes then invalidate the amendment so that the whole process has to be started over again, then the policy process would be quite heavyweight. I don't think that was the intent. There are already plugins that are not compiled with -fPIC, though. (megahal and wine have some on my system.) Hmm, but is there a reason against that, are we certain that those plugins must be relocatable? That's a technical question which needs a technical answer -- and I don't have it. (Not at midnight, at least :). I'm under the impression, though, that if the plugins are not relocatable, their code pages will not be shared between processes that use them. That would be wasteful. Richard Braakman
Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.)
On Fri, Apr 27, 2001 at 01:03:09PM +0200, Josip Rodin wrote: Manoj and I are only two people. Handling policy bugs is hard for a number of reasons: (1) There are a lot of them, and many of them are now quite long. (2) We don't have any official editorial rights, so unless a proposal has been seconded in the standard way, it's difficult to figure out what to do with it. I asked a week or so ago for help in handling this sort of stuff, but only one offer has been forthcoming. Well, I've done my part in submitting a patch as part of #66023 (Message-ID: [EMAIL PROTECTED]). Thanks! If you ignore the silly chatter in the bug log after that proposal, there's Shaleh saying that there would be several exceptions. He named two, and I explained what to do with those two, but he didn't like the explanation much. In the meantime, the QT library package changed, so it's not an exception anymore. Nobody explicitely said they second it, and nobody explicitely said they object. Several people (mostly maintainers of packages against which lintian barfs due to this) have said they would like this change in Policy, but not officially, even though I've asked. If those people don't care to second a proposal, I can't help... Oh, I'm fully in favour of that particular proposal (when we figure out what it should actually say): it's one of those cases where policy is obviously wrong; #72335 is another (which has a clear patch; somebody please second it!). It's just that there are a lot of bugs and it's hard for just one or two people to maintain them without the submitters lending a little bit of a helping hand by marking the proposals as amendments when the time comes. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.)
On Sat, Apr 28, 2001 at 12:18:46PM -0500, Manoj Srivastava wrote: I made one posting with such a list, but I've been swamped recently. I can start an automated posting of a list; with the master list being in policy CVS so that either Julian or I can updfate it; people can send me email for errata in that list. At this stage, I think the list would be unbearably long. I think we need to prune things somewhat first. I have a plan for when I've finished this batch of corrections Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
Richard == Richard Braakman [EMAIL PROTECTED] writes: Richard On Sat, Apr 28, 2001 at 12:37:22PM -0500, Manoj Srivastava wrote: +to by third party executables (binaries of other packages), +should be installed in the subdirectories of the Richard ^^^ Richard I would drop that the, to make clear that packages can create Richard their own subdirectory for the plugins. Umm. Perhaps one3 should specify ``the subdirectories of /usr/lib/package/: directory''? +file/usr/lib/file directory. Such files are exempt from +all the rules that govern ordinary shared libraries, except that +libraries, except that they must not be installed executable. Richard There seems to be something wrong with the structure of that Richard sentence. Nouse stutter in cut and paste. Such files are exempt from ll the rules that govern ordinary shared libraries, except that they must not be installed executable. Richard Anyway, do you really mean _all_ the rules? I would expect Richard that they should still be compiled with -fPIC, for the same Richard reasons as shared libraries -- memory pages with relocatable Richard code can otherwise not be shared between processes. (Please Richard correct me if plugins are not normally relocatable.) Richard Also, stripping with --strip-unneeded still seems like a good idea. Hmm. I assumed that since these were internal details of the package, one need not make policy about them, since internal detail should be left to the maintainers to implement. How about adding what you said above as an informative footnote? That way, every maintainer that reads policy shall no it is a good idea, and why, but policy shall not intrude into internal matters of the package. I definitely agree that what you say is a darned good idea, but I am not convinced that we need policy about that. manoj -- Never say you know a man until you have divided an inheritance with him. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sat, Apr 28, 2001 at 11:36:41PM -0500, Manoj Srivastava wrote: +to by third party executables (binaries of other packages), +should be installed in the subdirectories of the Richard ^^^ Richard I would drop that the, to make clear that packages can create Richard their own subdirectory for the plugins. Umm. Perhaps one3 should specify ``the subdirectories of /usr/lib/package/: directory''? Wouldn't that imply that one has to make /usr/lib/package/something/ subdirectory, or several of them? I agree with what Richard said, just drop the the. Richard Anyway, do you really mean _all_ the rules? I would expect Richard that they should still be compiled with -fPIC, for the same Richard reasons as shared libraries -- memory pages with relocatable Richard code can otherwise not be shared between processes. (Please Richard correct me if plugins are not normally relocatable.) Richard Also, stripping with --strip-unneeded still seems like a good idea. Hmm. I assumed that since these were internal details of the package, one need not make policy about them, since internal detail should be left to the maintainers to implement. How about adding what you said above as an informative footnote? That way, every maintainer that reads policy shall no it is a good idea, and why, but policy shall not intrude into internal matters of the package. I definitely agree that what you say is a darned good idea, but I am not convinced that we need policy about that. I think we should amend the proposal with a note that the plugins aren't exempt from stripping -- this is my oversight. Also, that is a should rule, so if there are exceptions, this won't cause serious bugs. I'm don't know about -fPIC, though, that is a must rule. A footnote would be fine, I suppose. -- Digital Electronic Being Intended for Assassination and Nullification
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
Josip Rodin [EMAIL PROTECTED] wrote: +Shared object files (i.e. filelibsoname.so/file) that are Seth Arnold noticed (in a private mail to me) how this stuff in parenthesis shouldn't be there (my mistake), because the plugins can be named differently -- the file name makes no practical difference, and e.g. I'd have to hack nessus-libraries to rename 12 *.nes files. I would simply change i.e. to e.g.. The example's a useful illustration. -- Colin Watson [EMAIL PROTECTED]
Bug#66023: [shaleh@valinux.com: Re: [PROPOSAL] Re: Shared libs vs. plugins.]
Just so it's noted. - Forwarded message from Sean 'Shaleh' Perry [EMAIL PROTECTED] - Delivery-date: Fri, 27 Apr 2001 18:58:28 +0200 X-Priority: 3 (Normal) Date: Fri, 27 Apr 2001 09:59:47 -0700 (PDT) Organization: VA Linux From: Sean 'Shaleh' Perry [EMAIL PROTECTED] To: Josip Rodin [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Re: Shared libs vs. plugins. Cc: [EMAIL PROTECTED], debian-policy@lists.debian.org I'd prefer if people seconded the diff in #66023 :) and then we can refine that stuff further if necessary. agreed, let's get this solved. (Seconded). - End forwarded message - -- Digital Electronic Being Intended for Assassination and Nullification
Re: [PROPOSAL] Re: Shared libs vs. plugins.
Josip == Josip Rodin [EMAIL PROTECTED] writes: Josip Our inability to get this into Policy is appaling, isn't it? : You are being too hard on yourself. Putting together a proposal that gathers seconds is non trivial; one has to convince people of the rationale, come up with the language that is acceptable to folks (not too general, and not to picayune). A synopsis of the arguments, stating both pro' and cons' may garner the debate and support you are looking for. I'll look into the bug history and see what I think of the issue. manoj -- He flung himself on his horse and rode madly off in all directions. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.)
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Pester people on IRC to second ones that you think are good ideas but Anthony haven't received any attention. This should be anyone on this list who is interesterd in the policy proposals (if you are not interested in policy, why are you here?) Anthony Make a list of outstanding proposals with their status and a Anthony brief description a la the old policy summaries joeyh did, Anthony or the even older policy todo list Christian Schwarz kept. I made one posting with such a list, but I've been swamped recently. I can start an automated posting of a list; with the master list being in policy CVS so that either Julian or I can updfate it; people can send me email for errata in that list. If this is a good idea, let me know, and I;ll see what I can do about a semi automatic posting of the state-of-policy report. manoj -- If you want the best things to happen in corporate life you have to find ways to be hospitable to the unusual person. You don't get innovation as a democratic process. You almost get it as an anti-democratic process. Certainly you get it as an anthitetical process, so you have to have an environment where the body of people are really amenable to change and can deal with the conflicts that arise out of change an innovation. Max DePree, chairman and CEO of Herman Miller Inc., Herman Miller's Secrets of Corporate Creativity, The Wall Street Journal, May 3, 1988 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#66023: [PROPOSAL] Re: Shared libs vs. plugins.
-BEGIN PGP SIGNED MESSAGE- Hi, I second this proposal, subject to the typographical and grammatical corrections included below. manoj --- policy.sgml.prevMon Jul 10 11:01:16 2000 +++ policy.sgml Mon Jul 10 11:41:12 2000 @@ -2158,6 +2158,27 @@ /p + p +Shared object files (i.e. filelibsoname.so/file) that are +not public libraries, that is, they are notmeant to be linked +to by third party executables (binaries of other packages), +should be installed in the subdirectories of the +file/usr/lib/file directory. Such files are exempt from +all the rules that govern ordinary shared libraries, except that +libraries, except that they must not be installed executable. +footnoteA common example are the so-called ``plug-ins'', +internal shared objects that are dynamically loaded by +programs using manref name=dlopen section=3./footnote + /p + + p +Packages containing shared libraries that may be linked to by +other packages' binaries, but which for some emcompelling/em +reason can not be installed in file/usr/lib/file directory, +may install the shared library files in subdirectories of the +file/usr/lib/file directory, in which case they should +arrange to add that directory in file/etc/ld.so.conf/file +in the package's post-installation script, and remove it in the +package's post-removal script. + /p + + p An ever increasing number of packages are using libtool to do their linking. The latest GNU libtools (= 1.3a) can take advantage of the metadata in the installed libtool archive - -- Many alligators will be slain, but the swamp will remain. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard http://www.gnupg.org/ iD8DBQE66v/LIbrau78kQkwRAREFAKC4qqTDbYrgTpegN8Jw9J92ivDghgCgoqIB CoRHpA5hnvLsSlPLKOjSOr0= =8Gj4 -END PGP SIGNATURE-
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sat, Apr 28, 2001 at 12:37:22PM -0500, Manoj Srivastava wrote: I second this proposal, subject to the typographical and grammatical corrections included below. Thanks. :) --- policy.sgml.prevMon Jul 10 11:01:16 2000 +++ policy.sgml Mon Jul 10 11:41:12 2000 @@ -2158,6 +2158,27 @@ /p + p +Shared object files (i.e. filelibsoname.so/file) that are Seth Arnold noticed (in a private mail to me) how this stuff in parenthesis shouldn't be there (my mistake), because the plugins can be named differently -- the file name makes no practical difference, and e.g. I'd have to hack nessus-libraries to rename 12 *.nes files. Since this correction wouldn't change the meaning of the proposal, please remove that part when you apply the diff to Policy. +not public libraries, that is, they are notmeant to be linked not meant -- Digital Electronic Being Intended for Assassination and Nullification
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
On Sat, Apr 28, 2001 at 12:37:22PM -0500, Manoj Srivastava wrote: +to by third party executables (binaries of other packages), +should be installed in the subdirectories of the ^^^ I would drop that the, to make clear that packages can create their own subdirectory for the plugins. +file/usr/lib/file directory. Such files are exempt from +all the rules that govern ordinary shared libraries, except that +libraries, except that they must not be installed executable. There seems to be something wrong with the structure of that sentence. Anyway, do you really mean _all_ the rules? I would expect that they should still be compiled with -fPIC, for the same reasons as shared libraries -- memory pages with relocatable code can otherwise not be shared between processes. (Please correct me if plugins are not normally relocatable.) Also, stripping with --strip-unneeded still seems like a good idea. Richard Braakman
Re: [PROPOSAL] Re: Shared libs vs. plugins.
On Thu, Apr 26, 2001 at 08:34:43PM -0700, Seth Arnold wrote: proposals. (Though in the section about seconding, it makes especial reference to registered Debian developers. Perhaps for the purposes of getting this bug taken care of, simply being An Interested User counts for proposals. If this is in error (Julian/Manoj?) let me know and I'll stop proposing things. :) You can certainly propose stuff, but I don't believe you can second stuff. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.)
On Fri, Apr 27, 2001 at 12:52:10AM +0100, Julian Gilbey wrote: Wichert, I think Geez, again? is the incorrect response to Daniel's mail. Bugs #42399 and #65345 against debian-policy have been outstanding for 1 year and 268 days and 322 days. #65345 even has a patch against lintian, though it is likely far too old to automatically apply. Our inability to get this into Policy is appaling, isn't it? : Manoj and I are only two people. Handling policy bugs is hard for a number of reasons: (1) There are a lot of them, and many of them are now quite long. (2) We don't have any official editorial rights, so unless a proposal has been seconded in the standard way, it's difficult to figure out what to do with it. I asked a week or so ago for help in handling this sort of stuff, but only one offer has been forthcoming. Well, I've done my part in submitting a patch as part of #66023 (Message-ID: [EMAIL PROTECTED]). If you ignore the silly chatter in the bug log after that proposal, there's Shaleh saying that there would be several exceptions. He named two, and I explained what to do with those two, but he didn't like the explanation much. In the meantime, the QT library package changed, so it's not an exception anymore. Nobody explicitely said they second it, and nobody explicitely said they object. Several people (mostly maintainers of packages against which lintian barfs due to this) have said they would like this change in Policy, but not officially, even though I've asked. If those people don't care to second a proposal, I can't help... Maybe people would notice this if we put some porn in that bug log. : -- Digital Electronic Being Intended for Assassination and Nullification
Re: [PROPOSAL] Re: Shared libs vs. plugins.
(missed this mail in my enormous inbox, sorry :) On Thu, Apr 26, 2001 at 08:34:43PM -0700, Seth Arnold wrote: They need to be exempt from the rule for shlibs file, too. See my attempt in #66023... Aye, too true. It may be easier for the proposal to not decide the paths involved -- it should be sufficient to say which paths are *not* allowed. Where else except in subdirs of /usr/lib should the --- policy.txtThu Apr 26 19:31:26 2001 +++ so-policy.txt Thu Apr 26 19:57:17 2001 @@ -2313,6 +2313,15 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often technically shared + libraries. Here you do the same thing in making stuff overly specific, as I did :) Someone might not want to call these libs plugins. Someone might want to define internal use diffently (two or more packages using them). If the plugin files are not installed in the default + search path of `ld.so' (currently /lib, /usr/lib), or in common + locations specified in `/etc/ld.so.conf' (such as /usr/X11R6/lib), + then the package's plugins are not required to comply with the + paragraph requiring symbolic links nor the `shlibs' sections + following. And any modification of ld.so.conf isn't described, but it happened (happens) `in the wild', like in xaw3d packages. I'd prefer if people seconded the diff in #66023 :) and then we can refine that stuff further if necessary. -- Digital Electronic Being Intended for Assassination and Nullification
Bug#66023: [PROPOSAL] Re: Shared libs vs. plugins.
I'm sending this to the bug address so it is recorded :o) - Forwarded message from Oliver Elphick olly@lfix.co.uk - Delivery-date: Fri, 27 Apr 2001 13:50:15 +0200 X-URL: http://www.lfix.co.uk/oliver To: Josip Rodin [EMAIL PROTECTED] cc: Julian Gilbey [EMAIL PROTECTED], debian-policy@lists.debian.org Subject: Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.) Date: Fri, 27 Apr 2001 12:48:12 +0100 From: Oliver Elphick olly@lfix.co.uk Josip Rodin wrote: Nobody explicitely said they second it, and nobody explicitely said they object. Several people (mostly maintainers of packages against which lintian barfs due to this) have said they would like this change in Policy, but not officially, even though I've asked. If those people don't care to second a proposal, I can't help... I second the proposal. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Draw nigh to God, and he will draw nigh to you. Cleanse your hands, ye sinners; and purify your hearts, ye double minded.James 4:8 - End forwarded message - -- Digital Electronic Being Intended for Assassination and Nullification
Bug#66023: [olly@lfix.co.uk: Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.)]
- Forwarded message from Oliver Elphick olly@lfix.co.uk - Date: Fri, 27 Apr 2001 12:48:12 +0100 From: Oliver Elphick olly@lfix.co.uk Subject: Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.) To: Josip Rodin [EMAIL PROTECTED] cc: Julian Gilbey [EMAIL PROTECTED], debian-policy@lists.debian.org Josip Rodin wrote: Nobody explicitely said they second it, and nobody explicitely said they object. Several people (mostly maintainers of packages against which lintian barfs due to this) have said they would like this change in Policy, but not officially, even though I've asked. If those people don't care to second a proposal, I can't help... I second the proposal. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Draw nigh to God, and he will draw nigh to you. Cleanse your hands, ye sinners; and purify your hearts, ye double minded.James 4:8 - End forwarded message - Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Bug#66023: PROPOSAL] Re: Shared libs vs. plugins.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can any developer second policy proposals? If so, I second this one too... (I have a package libwine that puts dynamically-loaded stuff into /usr/lib/wine) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iEYEARECAAYFAjrp0S4ACgkQA+GMa4PlEQ/n+ACgy3tfAnBpUI4xY5BsJ7qq++SW 7MEAn34JP2bmB5Q8iXRruQvDYzpCCBXh =dSpS -END PGP SIGNATURE-
[PROPOSAL] Re: Shared libs vs. plugins.
* Wichert Akkerman [EMAIL PROTECTED] [010426 11:18]: Previously Daniel Kobras wrote: For now I added a lintian overrides for this, but Sean asked me to bring up discussion here to clarify what lintian should treat as shared lib in the future in order to properly solve this issue. Geez, again? Basically a .so files that is not in /lib, /usr/lib, /usr/X11R6/lib or another directory listed in /etc/ld.so.conf is not a library (the dynamic linker can't find it anyway then) . Wichert, I think Geez, again? is the incorrect response to Daniel's mail. Bugs #42399 and #65345 against debian-policy have been outstanding for 1 year and 268 days and 322 days. #65345 even has a patch against lintian, though it is likely far too old to automatically apply. Sean forwarded the bugs from lintian to debian-policy 8 months after the patch was submitted. Sadly, Sean did not give comments why he did so; however, I hope Sean will forgive me when I suggest he did so because he likely wants an amendement to policy to document the correct handling of .so files outside of the standard (and configured) paths before he changes lintian. (If he were to change it now, afaict, lintian would not be truly policy compliant.) In that vein, I have taken a stab at a policy diff. I have made the diff against the .txt version -- hopefully no one will be upset at me. Since I am not a Debian developer, I do not know if I can submit a policy proposal. If that is the case, and there are no obvious flaws in this patch, I would hope someone would kindly resubmit the proposal in their own name, so this bug could be fixed finally. :) To make things easy for anyone, lets just explicitly place this text in the public domain, so that it can be included in debian-policy without those hideous copyright issues. --- policy.txt Thu Apr 26 13:56:29 2001 +++ so-policy.txt Thu Apr 26 14:04:10 2001 @@ -2313,6 +2313,13 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often shared libraries. If + the plugin files are not installed in the default search path of + `ld.so' (/lib, /usr/lib), or in common locations specified in + `/etc/ld.so.conf' (such as /usr/X11R6/lib), then the package is not + required to comply with the paragraph requiring symbolic links. + 9.1. The `shlibs' File Format - -- Earthlink: The #1 provider of unsolicited bulk email to the Internet. --- policy.txt Thu Apr 26 13:56:29 2001 +++ so-policy.txt Thu Apr 26 14:04:10 2001 @@ -2313,6 +2313,13 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins often have an extension .so. If + the plugin files are not installed in the default search path of + `ld.so' (/lib, /usr/lib), or in common locations specified in + `/etc/ld.so.conf' (such as /usr/X11R6/lib), then the package is not + required to comply with the paragraph requiring symbolic links. + 9.1. The `shlibs' File Format - pgpl5miLScG1p.pgp Description: PGP signature
Re: [PROPOSAL] Re: Shared libs vs. plugins.
On Thu, Apr 26, 2001 at 02:13:41PM -0700, Seth Arnold wrote: For now I added a lintian overrides for this, but Sean asked me to bring up discussion here to clarify what lintian should treat as shared lib in the future in order to properly solve this issue. Geez, again? Basically a .so files that is not in /lib, /usr/lib, /usr/X11R6/lib or another directory listed in /etc/ld.so.conf is not a library (the dynamic linker can't find it anyway then) . Wichert, I think Geez, again? is the incorrect response to Daniel's mail. Bugs #42399 and #65345 against debian-policy have been outstanding for 1 year and 268 days and 322 days. #65345 even has a patch against lintian, though it is likely far too old to automatically apply. Our inability to get this into Policy is appaling, isn't it? : --- policy.txtThu Apr 26 13:56:29 2001 +++ so-policy.txt Thu Apr 26 14:04:10 2001 @@ -2313,6 +2313,13 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often shared libraries. If + the plugin files are not installed in the default search path of + `ld.so' (/lib, /usr/lib), or in common locations specified in + `/etc/ld.so.conf' (such as /usr/X11R6/lib), then the package is not + required to comply with the paragraph requiring symbolic links. + They need to be exempt from the rule for shlibs file, too. See my attempt in #66023... -- Digital Electronic Being Intended for Assassination and Nullification
Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.)
On Thu, Apr 26, 2001 at 11:42:41PM +0200, Josip Rodin wrote: Wichert, I think Geez, again? is the incorrect response to Daniel's mail. Bugs #42399 and #65345 against debian-policy have been outstanding for 1 year and 268 days and 322 days. #65345 even has a patch against lintian, though it is likely far too old to automatically apply. Our inability to get this into Policy is appaling, isn't it? : Manoj and I are only two people. Handling policy bugs is hard for a number of reasons: (1) There are a lot of them, and many of them are now quite long. (2) We don't have any official editorial rights, so unless a proposal has been seconded in the standard way, it's difficult to figure out what to do with it. I asked a week or so ago for help in handling this sort of stuff, but only one offer has been forthcoming. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Old proposals again (Re: [PROPOSAL] Re: Shared libs vs. plugins.)
On Fri, Apr 27, 2001 at 12:52:10AM +0100, Julian Gilbey wrote: (2) We don't have any official editorial rights, so unless a proposal has been seconded in the standard way, it's difficult to figure out what to do with it. Pester people on IRC to second ones that you think are good ideas but haven't received any attention. Make a list of outstanding proposals with their status and a brief description a la the old policy summaries joeyh did, or the even older policy todo list Christian Schwarz kept. Send reminders to the proposers. Close suggested changes that haven't made it far enough to get a patch, and suggest the proposer open a new report with a patch and a summary of discussion so far. Cheers, aj, who notes the must/should/may thing seems to have died now that I've stopped disagreeing -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpOlrnE9AeXp.pgp Description: PGP signature
Re: [PROPOSAL] Re: Shared libs vs. plugins.
* Josip Rodin [EMAIL PROTECTED] [010426 14:54]: Our inability to get this into Policy is appaling, isn't it? : Especially since both you and Wichert have put effort into this -- that is two possible seconds for a proposal. I've taken a closer look at the policy-process text and I do not think I am actually allowed to make proposals. (Though in the section about seconding, it makes especial reference to registered Debian developers. Perhaps for the purposes of getting this bug taken care of, simply being An Interested User counts for proposals. If this is in error (Julian/Manoj?) let me know and I'll stop proposing things. :) They need to be exempt from the rule for shlibs file, too. See my attempt in #66023... Aye, too true. It may be easier for the proposal to not decide the paths involved -- it should be sufficient to say which paths are *not* allowed. Another shot (again placed in the public domain).: --- policy.txt Thu Apr 26 19:31:26 2001 +++ so-policy.txt Thu Apr 26 19:57:17 2001 @@ -2313,6 +2313,15 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often technically shared + libraries. If the plugin files are not installed in the default + search path of `ld.so' (currently /lib, /usr/lib), or in common + locations specified in `/etc/ld.so.conf' (such as /usr/X11R6/lib), + then the package's plugins are not required to comply with the + paragraph requiring symbolic links nor the `shlibs' sections + following. + 9.1. The `shlibs' File Format - -- Earthlink: The #1 provider of unsolicited bulk email to the Internet. --- policy.txt Thu Apr 26 19:31:26 2001 +++ so-policy.txt Thu Apr 26 19:57:17 2001 @@ -2313,6 +2313,15 @@ library links point to them, just before `dpkg' continues the installation and removes the links! + It is the case that some packages supply plugins intended for + internal use only and these plugins are often technically shared + libraries. If the plugin files are not installed in the default + search path of `ld.so' (currently /lib, /usr/lib), or in common + locations specified in `/etc/ld.so.conf' (such as /usr/X11R6/lib), + then the package's plugins are not required to comply with the + paragraph requiring symbolic links nor the `shlibs' sections + following. + 9.1. The `shlibs' File Format - pgpDcex5ySjTp.pgp Description: PGP signature
