Virtual packages
Section 2.3.5 says this: All packages should use virtual package names where appropriate, and arrange to create new ones if necessary. They should not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names. In reality, most (all?) virtual packages seem to fall into the category except privately, amongst a cooperating group of packages. As such, this paragraph doesn't seem to reflect reality very well. I could just propose a rewrite which made adding a package to the list the special case instead... but I think this merits rethinking anyway. What exactly is the list of virtual package names supposed to achieve, and why should it constrain those which are used? [I'm skipping the justifications for these various options, it should be obvious; all of these should have an addendum of and rewrite 2.3.5 accordingly] Option #1: Ditch the whole thing. Leave it to maintainers to sort it out, and replace this paragraph with guidelines about what virtual packages are for. Option #2: As #1, but build a list of virtual packages during the policy build process. This is based on the notion that the list is useful documentation, but I don't think this is a very good idea; the list would probably be out of date more often than not. Option #3: Ditch the file, and provide a tool in the debian-policy package which finds the current list. Option #4: Define what is meant by privately amoung packages more accurately, and rewrite the paragraph in terms of that. Other ideas? I'm hovering between #1 and #4. [Default option: bicker about it and get nothing useful done] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK
Re: Virtual packages
Andrew == Andrew Suffield [EMAIL PROTECTED] writes: Andrew In reality, most (all?) virtual packages seem to fall into Andrew the category except privately, amongst a cooperating group Andrew of packages. As such, this paragraph doesn't seem to reflect Andrew reality very well. I think the current process is that a bunch of maintainers feel there is a need for a virtual package name, and talk to people maintaining related packages, and work out some virtual package names that are then used privately. Once the number, and name, of the virtual packages has stabilized, and the expectation of what all these packages provide in common is hashed out, these names should be documented -- so that a new maintainer, starting with a new, package, that could provide or depend on these virtual packages, has a well known spot to go to to get the list of established virtual package names. I do think we need to re-write the para to state that the list is merely a registry, of sorts, of established virtual package names. manoj -- Take off your engineering hat and put on your management hat. Thiokol management, 1/27/86 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: Virtual packages
On Fri, Nov 22, 2002 at 01:41:08PM -0600, Manoj Srivastava wrote: I think the current process is that a bunch of maintainers feel there is a need for a virtual package name, and talk to people maintaining related packages, and work out some virtual package names that are then used privately. Once the number, and name, of the virtual packages has stabilized, and the expectation of what all these packages provide in common is hashed out, these names should be documented -- so that a new maintainer, starting with a new, package, that could provide or depend on these virtual packages, has a well known spot to go to to get the list of established virtual package names. I do think we need to re-write the para to state that the list is merely a registry, of sorts, of established virtual package names. Seconded. -- G. Branden Robinson|To Republicans, limited government Debian GNU/Linux |means not assisting people they [EMAIL PROTECTED] |would sooner see shoveled into mass http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn pgp2a66bivKz5.pgp Description: PGP signature
