List of Policy delegates
+ Colin Watson (Wed, 29 Apr 2009 22:51:55 +0100): Hey, I've committed a fix to our git repository, of course Oh, I see RT#1138 now, though I can't seem to find a mail mentioning these delegations/incorporations, but that could just be me not keeping up with may mail. Anyway, I wrote to ask if somebody could please submit a bug against www.debian.org providing a list of the list of current Policy delegates, so that http://www.debian.org/intro/organization can be updated. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
+ Russ Allbery (Mon, 06 Apr 2009 11:33:41 -0700): I don't see much real benefit in going out of our way to remove /var/games and it looks like it would be a bit annoying (at the least, require adding purge code to all games that put files in /var/games that would usually never be triggered). My inclination would be to say that this behavior is fine and perhaps we should officially bless it somewhere. I agree with this. We’re trying to move away (eg. with triggers) from stuff that has to be propagated to every maintainer scripts, and I really don’t see how removing an empty /var/games is such a big benefit that would make it worth our time to enforce rmdir’s everywhere. Additionally, what happens if package A and B both ship an empty /var/games (they both write their score files directly there, rather than a subdirectory), get both installed, then B gets purged and its postinst removes /var/games, and then A runs and tries to write to /var/games a score file, but the directory does no longer exist nor has the game write permission to create it. Is there or is there going to be a policy mandating that packages should not ship /var/games without shipping /var/games/name? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
+ Thorsten Glaser (Tue, 07 Apr 2009 18:54:59 +): Except the ton which sets LC_ALL=C to get sane (parsable, dependable, historically compatible) output. These would then unset all other LC_* and LANG and LANGUAGE, and only set LC_CTYPE to C.UTF-8 to get old behaviour but with UTF-8 (and mbrtowc and iswctype and and and) available. Isn’t setting LC_ALL=C.UTF-8 going to be about the same and less work? I’m genuinely interested if that would behave any different to what you said (unsetting all, setting LC_CTYPE). Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale
+ Steve Langasek (Mon, 06 Apr 2009 11:09:17 -0700): On Mon, Apr 06, 2009 at 05:33:35PM +, Thorsten Glaser wrote: If you need a specific locale (as seems from mksh, not sure if it is a bug in that program), you need to set it. You can only set a locale on a glibc-based system if it’s installed beforehand, which root needs to do. You can build-depend on the locales package and generate the locales you want locally, using LOCPATH to reference them. There's no need for Debian to guarantee the presence of a particular locale ahead of time - It is my impression that more packages than mksh could use an UTF-8 locale at build time (I’m afraid I don’t have pointers, but I’m sure I’ve come across at least a couple). Wouldn’t it be just better to change Debian’s default to make an UTF-8 locale available by default, rather than to force all those packages to play tricks with LOCPATH? I would go as far as suggesting that some package like libc6 itself ships the locale, both as a way of ensuring it’ll always be there, and of not forcing the locales package on every system (not sure if this was part of your concerns). Unfortunately, and from my limited knowledge and recent poking of this, it seems the supported locales for a running system are kept in a single file (/usr/lib/locale/locale-archive), so I’m unsure how the above could work out, if at all. particularly one that isn't actually useful to end users, as C.UTF-8 would be. Is that point really important? It is useful for building some packages, plus I’m sure we have pedant enough users that would prefer C.UTF-8 over en_US.UTF-8. :-P Finally, this stuff that Roger proposes about making “C” be UTF-8, and create some C.ASCII for people needing that, sounds shocking at the same time as appealing. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519941: 10.2 Libraries recommends use of /etc/ld.so.conf instead of /etc/ld.so.conf.d
* Steve Langasek [Mon, 16 Mar 2009 07:52:10 -0700]: On Mon, Mar 16, 2009 at 11:40:36AM +0100, Goswin von Brederlow wrote: Debian policy 10.2 Libraries says: | Packages containing shared libraries that may be linked to by other | packages' binaries, but which for some compelling reason can not be | installed in /usr/lib directory, may install the shared library files | in subdirectories of the /usr/lib directory, in which case they should | arrange to add that directory in /etc/ld.so.conf in the package's | post-installation script, and remove it in the package's post-removal | script. I believe this should be changed to dropping a file into /etc/ld.so.conf.d instead. Giving a policy for the filename might be a good idea too so there won't be conflicts. How about /etc/ld.so.conf/package.conf? This recommendation needs to be elminated entirely. It is *not* ok for packages that provide libraries to stick extra linker paths in the global configuration, whether by modifying ld.so.conf or by adding to /etc/ld.so.conf.d. Either the libraries provided by the packages are meant to be public, in which case they should be installed to the standard library path instead of needlessly adding another directory that's going to be globally visible anyway; or they should not, and the cooperating packages should use rpath instead. Use of rpath should still be discouraged, but if someone is bound and determined to violate the FHS with their library paths in order to have private libraries, they should make them really private with rpath instead of using this compromise solution that takes the worst of each approach. +1 -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#446712: [PATCH] Allow comments in debian/control (bug#446712)
* Russ Allbery [Sat, 28 Feb 2009 22:07:36 -0800]: It occurred to me to check behavior with multiline fields as well. Here's a slightly modified version documenting that. Does this still look good to you? (And also requesting seconds from others.) --- a/policy.sgml +++ b/policy.sgml @@ -2450,6 +2450,14 @@ Package: libc6 See ref id=substvars for details. /p + p + In addition to the control file syntax described qref + id=controlsyntaxabove/qref, this file may also contain + comment lines starting with tt#/tt. All such lines are + ignored, even in the middle of continuation lines for a + multiline field, and do not end a multiline field. + /p + /sect Seconded, with or without: + comment lines starting with tt#/tt preceded by no whitespace. Or some wording to that effect. The rationale is that it's very common for files that accept #-style comments to accept them if # is preceded by whitespace, but this is not the case in control files. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Vainica Doble - Chinita de Shangai -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473439: pick consistent terminology for category/component/area
* Russ Allbery [Sun, 25 Jan 2009 15:37:37 -0800]: I think Policy should not attempt to make up its own terminology here, so I'd like to change it to match either dak or the Social Contract. After thinking about it for a bit, I favor going to the terminology of the Social Contract with a minor modification (distribution areas instead of just areas) in part because of Ian's point and in part because I think it's meaningful to suppose that component refers to a technical capability of dak whereas distribution area refers to a concept within Debian as a project. The above was written in July of last year. The only reaction that I got to this proposal is a comment from Giacomo that didn't object but suggested standardizing more of the terminology while we're at it. But I don't think there's been much progress on that front. As mentioned, I'm not sure we need to match the terminology in dak as long as we're not confusing about it. dak is referring to technical capabilities which are used to implement certain features. I still think distribution area is a good name for this, better than categories. However, there doesn't appear to be any consensus on this right now. So this is a ping to see if we do have consensus and people just haven't said, or if we don't. If we don't have consensus, my inclination is to close this bug and continue using categories, since I don't think anything else uses category in a confusing way. I don't want to just leave the bug open; it doesn't seem likely that anything fundamental is going to change about this bug report in the future. Although I slightly favour component over area, I think your reasoning above is sound, and I'll happily take distribution area over category, particularly if the term component is mentioned in a footnote, as your patch does. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Pablo Milanés - Libertad -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian version numbers and strcmp()
Thanks everybody for their responses. I'll learn to live with this (small) unhappiness. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The first step on the road to wisdom is the admission of ignorance. The second step is realizing that you don't have to blab it to the world. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian version numbers and strcmp()
Hello, I'd like to hear from members of this list what they think about the following issue: I just noticed that to determine whether two Debian versions are equal, one can't use strcmp() or similar, and must implement the full comparison algorithm. For example, 0.9 and 0.09 are the same version according to Policy. I'm tempted to say this is rather unfortunate: I always believed our version numbers to be comparable for *equality* using standard tools, and that the Policy algorithm was there just to sort different version strings. I think this is a reasonable expectation, too. (I realize Policy talks about comparison.) Is there a reason for it to be this way? Is there a reason that would advise against changing it? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - I love you, Shirley, I'm not ashamed to say. - If you love me, then you'll want me to be happy. Even if I'm not with you. - I don't love you that much. -- Denny Crane and Shirley Schmidt -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509935: decide whether Uploaders is parsed per RFC 5322
* Russ Allbery [Mon, 19 Jan 2009 12:10:55 -0800]: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: While I can only agree on the technical ground of this proposal, I have quite a number of scripts (including popcon) that depend on the ability to extract the maintainer name from the Maintainer/Uploaders field. I suspect others developers and debian-qa might have others. Adding quotes around the maintainer name break the interface somehow. Using the full Maintainer field is often problematic because: 1) we might not want to display the email address. 2) we might want to merge entries from the same maintainer using different email adresses for different packages. (popcon go farther and check for different capitalization). So I would suggest we keep the format 'Name email' and forbid dot and commas. Developers that need them could use UTF-8 variants of those. Well, I really don't want to prohibit dots. We allow dots now and they don't pose any problems, other than the note in Policy that you need to put quotes around the name if you use it in an e-mail To: field (which presumably all of our software already deals with). I think dots should be allowed, yes, and be allowed unquoted. Your point about not wanting to change software that parses the name is well-taken. I think, though, that if we say that you may only put double-quotes around the name if there is a comma in the name and otherwise the quotes should be omitted, that would minimize the problem. Only a handful of existing maintainers would be affected (namely those maintainers who are having trouble right now), so updating software wouldn't be that urgent. I think we should *consider* do without commas at all, if losing them is something we could live with. I realize that would be annoying for people that have a comma in their name, so I'm not right away saying we should forbid them. But I really think we should consider it, because even if commas have to be quoted, you've already lost the ability to parse the Uploaders field with split /\s*,\s*/, which I think would be a loss, since that works for all other fields. (Oh, and if we do without commas, we should do without quoting as well IMHO.) Just my 2¢, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: directory for icons
* Thomas Lange [Fri, 31 Aug 2007 13:57:49 +0200]: Hi my package fai-server will include a command faimond-gui which needs some icons. Were should I put those icons? /usr/share/packagename/icons or /usr/share/commandname/icons or /usr/share/icons/packagename or a different location? I could not find anything in the policy, developers-reference or FHS concerning this. I think that if it's a 32x32 .xpm file, the standard location is /usr/share/pixmaps. You probably want that. PNG icons get normally shipped somewhere under /usr/share/icons, but it seems each desktop has its own policies about exactly where. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Alaska y Dinarama - Cebras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
* Hubert Chan [Mon, 31 Jul 2006 00:09:26 -0400]: Not having used the DELAYED queue before, is it possible for the maintainer to reject an upload without making their own upload? e.g. if the NMU is broken, but it will take me more than a week to test a proper fix. Or if I decide that the package shouldn't be changed after all. etc. No, there is not. If the NMU is horribly broken, telling that to the NMUer should get them into doing something (withdrawing it, or fixing it). If not, and it's really important that the upload does not make into the archive, you can e.g. just reupload the current version (e.g. 1.2-3 as 1.2-4, which is bigger than 1.2-3.1). Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378386: [PROPOSAL] Include the GFDL in the set shipped in /usr/share/common-licenses
Package: debian-policy Version: 3.7.2.1 Severity: wishlist Tags: patch Hello. In [1], Joerg Jaspert initiated discussion about including more licenses in the set of licenses shipped in /usr/share/common-licensed. As part of the discussion I inquired in [2] about the possibility of adding the GFDL to that set, given the number of packages that ship some contents under this license. Since at least one of the Policy editors, namely Manoj Srivastava, agreed in [3] that the GFDL passes the criteria for inclusion, I'm now transforming the mentioned informal discussion into a formal request. [1] http://lists.debian.org/debian-policy/2006/06/msg00100.html [2] http://lists.debian.org/debian-policy/2006/06/msg00109.html [3] http://lists.debian.org/debian-policy/2006/06/msg00206.html Attached is a patch with the possible wording for the change. Also, if somebody wonders as for why the change is not first commited in the base-files package, and let Policy catch up on reality later: as per /usr/share/doc/base-files/FAQ, the base-files has delegated that decision to the Policy editors. I will submit a bug against base-files after an updated debian-policy is uploaded, or this bug marked by pending by one of the editors. Thanks! -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org We learned that the Linux load average rolls over at 1024. And we actually found this out empirically. -- H. Peter Anvin from kernel.org --- ./policy.sgml~ 2006-07-16 00:14:47.0 +0200 +++ ./policy.sgml 2006-07-16 00:17:56.0 +0200 @@ -8618,8 +8618,8 @@ p Packages distributed under the UCB BSD license, the Artistic - license, the GNU GPL, and the GNU LGPL should refer to the - corresponding files + license, the GNU GPL, and the GNU LGPL, or ship documentation + under the GFDL, should refer to the corresponding files underfile/usr/share/common-licenses/file,footnote p For example, @@ -8627,6 +8627,7 @@ file/usr/share/common-licenses/BSD/file, file/usr/share/common-licenses/GPL/file, file/usr/share/common-licenses/LGPL/file, + file/usr/share/common-licenses/GFDL/file, file/usr/share/common-licenses/GPL-2/file, and file/usr/share/common-licenses/LGPL-2.1/file, and so on. /p
Re: Including more licenses in 12.5
* Manoj Srivastava [Mon, 19 Jun 2006 08:59:23 -0500]: I'll give the numbers on my system so as to affirm that the proportions are quite similar: __ grep-status -s Source '.' | sort -u | wc -l 1149 442 __ find /usr/share/doc -type f -name copyright | wc -l 3615 1448 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+General' | 915 2154 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l Artistic | wc -l 504 177 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+Lesser' | wc -l 252 181 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+Library' | wc -l 174 117 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'Berkeley' | wc -l 82 46 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'Python.+Software' | wc -l 17 19 __ find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'Zope' | wc -l 15 13 And now, I will give an extra command: % find /usr/share/doc -type f -name copyright | \ xargs egrep -l 'GNU.+Documentation' | wc -l 168 (On my laptop this number is 268.) This is because one and each of the binary packages coming from kde.org (of which there are around 500) ships a copy of the GFDL. I would certainly like to see this license shipped as a common license. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Los Planetas - San Juan de la Cruz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
outdated changelog timestamps (was Re: Date and Upsteam-URL fields)
* Goswin von Brederlow [Sun, 11 Jun 2006 19:49:50 +0200]: David Weinehall [EMAIL PROTECTED] writes: On Fri, Jun 09, 2006 at 10:04:48PM +0200, Bill Allombert wrote: Sometimes, the changelog will tell you the package was last changed 3 month ago while actually it was changed yesterday and build and uploaded today. This can lead you to go on a wild-goose chase if you do not know about the problem. [snip] Sure but adding entries to the changelog does not magically update the date. Then I suggest you start using dch. Or an editor mode/plugin/whatever that updates the time on save in changelogs. Very usefull. And hateful (IMHO) when this results in every commit you do in your debian packaging in changes in the timestamp of the changelog (and for co-maintained packages, the name as well). I've thought about this several times, and I think what'd make me happy would be, instead of this dist=UNRELEASED stuff to mark work in progress in VCS, something like: package (1.1) unstable; urgency=low [ Joe Random ] * Foo. -- UNRELEASED And then, dch -r would be run by the person uploading, placing their name and current timestamp in the final changelog, optionally removing the [Joe Random] bit iff there is no other name tag, and Joe Random is the one uploading. Pity that dpkg-parsechangelog would choke on that, and also, I haven't heard anybody express discontent about this, so maybe I'm too picky, which makes me think that everybody is happy with using dist=UNRELEASED and updating the timestamp with each commit (or not doing, and risk forgetting to do so the last time before uploading). Cheers, (I guess followups should go to -devel and not -policy.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joan Manuel Serrat - Soy lo prohibido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Date and Upsteam-URL fields
* Margarita Manterola [Thu, 08 Jun 2006 23:35:54 -0300]: So, in any case, I'd encourage you to patch dpkg to handle a new Homepage field, and submit the patch. Once this is being used by a big number of packages, you might bring this up again. I'd really like to have the Homepage field in dpkg, although I doubt it would enter policy. You can start without patching dpkg: Package: foo ... XB-Homepage: http://www.foo.org That will make a Homepage field end in the binary control information, and thus in the Packages file. I've recently added a X-VCS-Bzr header to a couple packages of mine (in the .dsc, though, not in the binaries, so it's only in the Sources file). -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - El rocanrol de los idiotas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-fonts-devel] ttf-lang-* virtual packages
* Adrian von Bidder [Mon, 20 Mar 2006 19:37:15 +0100]: Yo over there on d-policy! Explanation: we're discussing how to better organize fonts in Debian. One idea is to use virtual packages to have fonts specify their supported charsets and/or languages in a ttf-lang-* and/or ttf-charset-* virtual package name space. Amongst others, the ability of input methods to recommend (or depend?) on proper fonts was mentioned as an advantage of this. On Sunday 19 March 2006 09:06, Christian Perrier wrote: We request for the creation of virtual packages named ttf-lang-langname so that all font packages that are targeted for the supprot of a given language can add a Provides on the relevant virtual package(s). The only drawback here is that virtual packages creation is a process that is quite precisely defined in http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.tx t and we would need to request for the creation of *a lot* of virtual packages...:-) Well, I guess we need input from the policy gods here ;-) Depending on your use case, formally requesting such virtual packages may not be needed. From Policy 3.6: 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. (See also Section 7.4, `Virtual packages - `Provides'') So if the set of packages that would need to depend or recommend a ttf-lang-foo (or whatever name is finally picked) is reduced and somehow related, this can probably be considered cooperation. Just for reference, here are some statistics (generated with the attached script): Number of virtual packages defined in Policy: 73 Number virtual packages provided in the archive (i386): 1611 Number of v.p. defined in Policy and provided in the archive: 62 Number of v.p. defined in Policy but not provided in the archive: 11 Number of v.p. NOT defined in Policy but provided in the archive: 1549 HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As scarce as truth is, the supply has always been in excess of the demand. -- Josh Billings virtual-packages-stats.sh Description: Bourne shell script
Re: Autobuilding and the build-arch target, again
* Wouter Verhelst [Wed, 25 Jan 2006 10:14:26 +0100]: Yes, but only if packages who declare build-depends-indep without having build-arch exist. Anyone feel like finding that out? ;-) Simon run a test through the archive prior to sending his mail, to find out. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A lie can go round the world before the truth has got its boots on. -- Terry Pratchett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 - must
* Kari Pahula [Wed, 04 Jan 2006 11:37:46 +0200]: The reason why I got to think about this policy change was because I noticed that every arch's buildd was calling my build-indep and having doxygen generate 30 MBs of docs. I was suggested on IRC to either generate the docs in binary-indep or ask for a policy change. Or move doxygen from Build-Depends to Build-Depends-Indep, and gracefully ignore its absence in the build target, if possible. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Y sobre todo, tienes mucho de gilipollas. -- B.C.S. addressing P.G.i.Q in b8g -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329762: Relaxation and documentation of the -fPIC constraint
* Loïc Minier [Fri, 23 Sep 2005 10:59:05 +0200]: - permit building of static libraries with -fPIC (I don't think this has any reason to be forbidden, does it?) Then, I'd say it should be mentioned that such libraries are expected (must?) be named like this: libfoo_pic.a. Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Old men are fond of giving good advice to console themselves for their inability to set a bad example. -- La Rochefoucauld, Maxims -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure to add sub-policies
* Manoj Srivastava [Tue, 26 Jul 2005 23:10:26 -0500]: When the policy is deemed to be sufficiently mature, and when most packages in question are following it anyway, the new sub-policy can be submitted for inclusion into the main policy as a normal proposal (and usually these sub-policies can be integrated pretty rapidly, since the kinks have already been worked out And once it's been integrated, does it have to follow the procedures that apply to the main Policy document in order to be updated? Or does the control of this document remain more or less in the hands of those domain experts? At first sight, I think the second option makes more sense, since the changes are usually discussed and agreed upon in their own list. Though they could nevertheless be posted to -policy for a quick review. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 A conclusion is simply the place where someone got tired of thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291026: debhelper uses which
* Thomas Hood [Fri, 13 May 2005 23:54:52 +0200]: (Is there a way to browse debian-policy in CVS?) If I understood correctly, http://cvs.debian.org/?cvsroot=debian-policy may be what you want. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 It is impossible to make anything foolproof because fools are so ingenious. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
