Bug#92423: PROPOSAL] renaming of debian/rules file
Peter Palfrader [EMAIL PROTECTED] writes: On Sun, 01 Apr 2001, Bas Zoetekouw wrote: Hi Taral! You wrote: It should most certainly be debian/rulz, not rulez. Why not make it d3b1an/rulz, then? d3b14n/ru|z seems like a good choice. No, no. d3b!4n/ru|z is much clearer. Thomas
Re: Definition of alphanumeric?
Julian == Julian Gilbey [EMAIL PROTECTED] writes:
Julian On Sun, Apr 01, 2001 at 03:50:39PM +0200, Marcus Brinkmann wrote:
policy uses alphanumeric to define version numbers. Is this only a-zA-Z0-9,
or does this include the _? As the _ is used as a seperator in Debian
package file names, this would be perverse, but I would like to stay on the
safe side.
Julian No, only a-zA-Z0-9 should be allowed. I have no idea whether this is
Julian enforced anywhere, but this should probably be spelled out in policy.
Here is what policy says, in part:
--
epoch
This is a single (generally small) unsigned integer.
upstream-version
The upstream-version may contain only alphanumerics and the
characters `.' `+' `-' `:' (full stop, plus, hyphen, colon) and
should start with a digit. If there is no debian-revision then
hyphens are not allowed; if there is no epoch then colons are
not allowed.
debian-revision
The debian-revision may contain only alphanumerics and the
characters `+' and `.' (plus and full stop).
--
So there is no component that takes merely alphanumerics;
policy is already quite explicit about this.
--
From The Free On-line Dictionary of Computing (19 Jan 01) [foldoc]:
alphanumeric
character A decimal digit or a letter (upper or lower case).
Typically, letters means only English letters ({ASCII} A-Z
plus a-z) but it may also include non-English letters in the
Roman alphabet, e.g., e-{acute}, c-{cedilla}, the {thorn
letter}, and so on. Perversely, it may also include the
{underscore} character in some contexts.
--
I suggest we note that as far as policy is concerned,
alphanumeric has the most restrictive definition, namely,
character A decimal digit or a letter (upper or lower case), where
letters means only {ASCII} A-Z plus a-z (This can be an annotative
footnote).
manoj
--
New York... when civilization falls apart, remember, we were way
ahead of you. David Letterman
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: Definition of alphanumeric?
Adam == Adam Heath [EMAIL PROTECTED] writes: PWD=`pwd` Adam Btw, I think this is bad. They should use CURDIR. __ echo $CURDIR __ So, what is the provenance of this CURDIR variable? Has it been blessed by POSIX? indeed not. However, I see that both $PWD and the pwd utility are sanctioned by POSIX; so for maximal portability scripts should *NOT* use CURDIR, the should either use PWD, or call pwd themselves, like the example did. manoj -- People are like onions -- you cut them up, and they make you cry. 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: Definition of alphanumeric?
* Antti-Juhani Kaijanaho [EMAIL PROTECTED] [010402 01:32]: On 20010402T030737-0500, Manoj Srivastava wrote: So, what is the provenance of this CURDIR variable? Has it been blessed by POSIX? indeed not. I believe this is irrelevant, as portable make is next to useless. I'll admit I don't know make very well, but a cursory read-through of O'Reilly's make book did not give me this impression. Furthermore, there is no need to complicate matters worse -- if CURDIR is not portable but PWD is portable, then only nutters would suggest using CURDIR instead of PWD. (Apologies to the original poster; I figure the portability issue was unknown to him or her.) There is no need to go out of our way to make software unportable. (*sigh* Lookit me ma! Me know English good!) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Bug#92423: PROPOSAL] renaming of debian/rules file
On Mon, Apr 02, 2001 at 12:45:54AM +0100, Julian Gilbey wrote: It should most certainly be debian/rulz, not rulez. Why not make it d3b1an/rulz, then? d3b14n/ru|z seems like a good choice. Although the | could cause fun were someone to forget to quote it ;-) Yeah, but we won't forget to do it, we're 313371!!11 ;) -- Digital Electronic Being Intended for Assassination and Nullification
Re: Definition of alphanumeric?
On Mon, Apr 02, 2001 at 03:07:37AM -0500, Manoj Srivastava wrote: PWD=`pwd` Adam Btw, I think this is bad. They should use CURDIR. __ echo $CURDIR __ So, what is the provenance of this CURDIR variable? Has it been blessed by POSIX? indeed not. However, I see that both $PWD and the pwd utility are sanctioned by POSIX; so for maximal portability scripts should *NOT* use CURDIR, the should either use PWD, or call pwd themselves, like the example did. Note that this is probably not relevant to my problem. CURDIR is the same string as PWD, it is not proetcted so it can be used in make rules like this: foo: $(MYDIR)/bar If $(MYDIR) is something with a : or %, make breaks. I don't know if it is possible to make this work at all by quoting, but this is what you find in gawk currently (with MYDIR being something evaluating to pwd, but chnaging it to CURDIR doesn't change anythin). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Bug#92423: marked as done ([PROPOSAL] renaming of debian/rules file)
Your message dated 02 Apr 2001 08:52:25 -0500
with message-id [EMAIL PROTECTED]
and subject line [PROPOSAL] renaming of debian/rules file
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Darren Benham
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 1 Apr 2001 12:59:31 +
From [EMAIL PROTECTED] Sun Apr 01 07:59:31 2001
Return-path: [EMAIL PROTECTED]
Received: from (mail.cps.matrix.com.br) [200.196.9.5]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 14jhS7-0004KK-00; Sun, 01 Apr 2001 07:59:31 -0500
Received: from godzillah.rivendell.sol (srv1.rcm.org.br [200.196.10.141])
by mail.cps.matrix.com.br (8.11.1/8.11.1) with ESMTP id f31DDY625649;
Sun, 1 Apr 2001 10:13:35 -0300 (BRT)
(envelope-from [EMAIL PROTECTED])
Received: by godzillah.rivendell.sol (Postfix, from userid 1000)
id 5D4A9585B; Sun, 1 Apr 2001 09:59:14 -0300 (BRT)
Date: Sun, 1 Apr 2001 09:59:14 -0300
From: Henrique M Holschuh [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: [PROPOSAL] renaming of debian/rules file
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Reportbug-Version: 1.14
Delivered-To: [EMAIL PROTECTED]
Package: debian-policy
Version: 3.5.2.0
Severity: wishlist
It is about time we recognize the truth. We have been constantly called as
the most elitist of the GNU/Linux distribuitons, and this is true.
So, I propose we make clear that we are indeed '1337 and rename the
debian/rules file to debian/rulez. Anyone who cannot see the benefits of
the added c00lness effect such a change would bring is not fit to be One Of
Us[TM].
The transition from the old to the new system can be easily performed by
including a test in dpkg-source, so that a debian/rules - debian/rulez
symlink is added to the source deb if the debian/rules file is not present
and the debian/rulez file is. It should also automatically call the
atention of any lamerz that try to build a package without renaming the
rules file to rulez.
I also propose we add the following target to the standard debian/rulez
target list:
m00: should display an ASCII-art of a stoned cow, in deference of the s1kr3t
bovine powers behind the Debian packaging system, and the magic smoke of
Holy Cow that is portrayed in our logo.
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux godzillah.rivendell.sol 2.2.19 #1 Thu Mar 29 19:31:38 BRT 2001
i586
Versions of packages debian-policy depends on:
ii fileutils 4.0.43-1 GNU file management utilities.
PS: If you took this email seriously, hit your head with a hammer and think
again. It was sent in the April fools day, after all. If you second this,
you're seriously deranged, and in severe need of either more coffee, or sleep.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
---
Received: (at 92423-done) by bugs.debian.org; 2 Apr 2001 14:01:00 +
From [EMAIL PROTECTED] Mon Apr 02 09:01:00 2001
Return-path: [EMAIL PROTECTED]
Received: from (glaurung.green-gryphon.com) [63.161.160.94] (srivasta)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 14k4tA-0005CL-00; Mon, 02 Apr 2001 09:01:00 -0500
Received: (from [EMAIL PROTECTED])
by glaurung.green-gryphon.com (8.12.0.Beta5/8.12.0.Beta5/Debian
8.12.0-1) id f32DqQid031858;
Mon, 2 Apr 2001 08:52:26 -0500
X-Mailer: emacs 21.0.100.1 (via feedmail 9-beta-7 I)
Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] renaming of debian/rules file
From: Manoj Srivastava [EMAIL PROTECTED]
X-URL: http://www.debian.org/%7Esrivasta/
Organization: The Debian Project
Mail-Copies-To: nobody
X-Time: Mon Apr 2 08:52:25 2001
X-Face: [EMAIL PROTECTED]/;Y^gTjR\T^B'fbeuVGiyKrvbfKJl!^e|e:iu(kJ6c|QYB57LP*|t
YlP~HF/=h:[EMAIL PROTECTED]:6Cj0kd#4]*D,|0djf'CVlXkI,aV4\}?d_KEqsN{Nnt7
78OsbQ[56/!nisvyB/uA5Q.{)gm6?q.j71ww.b9b]-sG8zNt%KkIaxWg1VcjZk[hBQ]j~`Wq
Xl,y1a!(6`UM{~'X[Y_,Bv+}=L\SS*mA8=s;!=O`ja|@PEzbi0}Qp,`Z\:6:OmRi*
Date: 02 Apr 2001 08:52:25 -0500
Message-ID: [EMAIL PROTECTED]
Lines: 7
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Delivered-To: [EMAIL PROTECTED]
--
Having children is like
Re: Definition of alphanumeric?
On Mon, Apr 02, 2001 at 03:01:42AM -0500, Manoj Srivastava wrote: Julian == Julian Gilbey [EMAIL PROTECTED] writes: Julian On Sun, Apr 01, 2001 at 03:50:39PM +0200, Marcus Brinkmann wrote: policy uses alphanumeric to define version numbers. Is this only a-zA-Z0-9, or does this include the _? As the _ is used as a seperator in Debian package file names, this would be perverse, but I would like to stay on the safe side. Julian No, only a-zA-Z0-9 should be allowed. I have no idea whether this is Julian enforced anywhere, but this should probably be spelled out in policy. Sorry, I wasn't clear and have now been corrected twice: as Manoj indicated, I meant to say only a-zA-Z0-9 should be allowed *as alphanumerics*. I like the idea of a footnote to this effect. 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#92589: there is no standard way to check if an init script is installed
Package: debian-policy Version: 3.5.2.0 Severity: normal The Debian policy specifies (10.3.1) that maintainer scripts should not assume whether or not a specific implementation of the handling of init scripts is used. It provides a tool, update-rc.d, that has to be used to install or remove an init script activation. However, it does not provide a standard way to check the current status of an init script. Administation packages that need to know the situation of an init script (e.g. webmin-core, ksysv, rcconf, etc.) have to implement checks for all possible implementations. Most of them assume the symlink scheme is used. The reasonnable solution would seem to be to offer an additionnal standard tool : check-rc.d that would take as a parameter an init script, and provide information on the current situation of the script. For example : # check-rc.d installed /etc/init.d/apache echo true true # check-rc.d startstop /etc/init.d/apache STOP 0 20 STOP 1 20 START 3 95 START 4 95 START 5 95 STOP 6 20 -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux tigreraye 2.4.2-ac28 #1 SMP lun avr 2 01:44:11 CEST 2001 i686 Versions of packages debian-policy depends on: ii fileutils 4.0.43-1 GNU file management utilities. -- Jean-Philippe Guérard
Bug#92589: there is no standard way to check if an init script is installed
On Mon, 02 Apr 2001, Jean-Philippe Guérard wrote: The Debian policy specifies (10.3.1) that maintainer scripts should not assume whether or not a specific implementation of the handling of init scripts is used. It provides a tool, update-rc.d, that has to be used to install or remove an init script activation. However, it does not provide a standard way to check the current status of an init script. It will, soon. Please verify if invoke-rc.d --query (initscript) (action) in the accepted proposal #76868 is enough for your needs. script (e.g. webmin-core, ksysv, rcconf, etc.) have to implement checks for all possible implementations. They will be forbidden of doing so eventually, so please do check if the proposed functionality of #76868 is enough. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Definition of alphanumeric?
On Mon, Apr 02, 2001 at 08:50:30AM -0500, Manoj Srivastava wrote: Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj So, what is the provenance of this CURDIR variable? Has it Manoj been blessed by POSIX? indeed not. However, I see that both $PWD and Manoj the pwd utility are sanctioned by POSIX; so for maximal portability Manoj scripts should *NOT* use CURDIR, the should either use PWD, or call Manoj pwd themselves, like the example did. I know it is bad form replying to oneself, but, after some sleep, I realize that the provenance of CURDIR being a convenience variable set by GNU make is as valid as anything POSIX says. What? Manoj, prone to knee-jerk conservativism? Never. /me grins evilly and hides -- G. Branden Robinson |There's nothing an agnostic can't do Debian GNU/Linux|if he doesn't know whether he believes [EMAIL PROTECTED] |in it or not. http://www.debian.org/~branden/ |-- Graham Chapman pgpJ3mGuEY0L4.pgp Description: PGP signature
Policy rewrite: chaps 11-13
Here's the last installment of my comments on the existing policy document 11.2, describing .la files: [they] contain a lot of useful info ... (e.g. dependency libraries for static linking) Would dependency information be better? 11.2, penultimate paragraph reads: Packages that use libtool to create shared libraries should include the _.la_ files in the _-dev_ packages, with the exception that if the package relies on libtool's _libltdl_ library, in which case the .la files must go in the run-time library package. This is a good idea in general, and especially for static linking issues. What does the indicated This refer to -- that packages should include the .la files in the -dev or run-time package? 11.3 The explanation of soname is wrong; for example: polya:~ $ objdump -x /usr/lib/libxml.so.1.8.11 | grep SONAME objdump: /usr/lib/libxml.so.1.8.11: no symbols SONAME libxml.so.1 So this paragraph needs rewriting somehow. 11.7.5 What does the following mean? However, programs that require dotfiles in order to operate sensibly (dotfiles that they do not create themselves automatically, that is) are a bad thing, and programs should be configured by the Debian default installation as close to normal as possible. (It's the last part I don't understand.) 11.8 Logrotate: should it be a policy directive (packages should rotate their logfiles using logrotate) and written in a more formal style? 11.9 There's a paragraph about changing permissions and security policies (beginning You must not arrange that the system administrator...). Is this any longer true now that we have dpkg-statoverride? 11.9 Statically allocated ids: If you need a statically allocated id, you must ask for a user or group id from the base system maintainer, and must not release the package until you have been allocated one. Once you have been allocated one you must make the package depend on a version of the base system with the id present in `/etc/passwd' or `/etc/group', or alternatively arrange for your package to create the user or group itself with the correct id (using `adduser') in its pre- or post-installation script (the latter is to be preferred if it is possible). What is the latter? Is it the latter alternative (or alternatively ...) or the postinst instead of the preinst? I would guess that it means postinst is preferred to preinst, but I may be wrong here. 12.1 The list of arches is probably out of date. Maybe policy shold not be so directive here, perhaps referring to the output of dpkg-architecture -h? 12.2 The last para reads: If a package wants to install an example entry into `/etc/inetd.conf', the entry must be preceded with exactly one hash character (`#'). Such lines are treated as `commented out by user' by the `update-inetd' script and are not changed or activated during a package updates. This isn't very meaningful as it stands. Either the whole paragraph should be removed or a better explanation of what it's talking about should be given. 12.5 3. Web document root and web applications Pardon my ignorance, but what's a web application and what are examples? 12.6 Mailboxes are generally [mode] 660 user.mail unless the user has chosen otherwise. Should this be unless the system administrator has chosen otherwise.? 12.6 All MTA packages must include a newaliases program, so there should be a para reminding that all MTAs must Provide, Conflict and Replace mail-transport-agent. 12.6 last para: check for the existance of /etc/mailname: If it does not exist it should prompt the user What is it? I think it's probably the pre/postinst. 12.8 There's a footnote (7) which says Rationale: clarifies the language...; surely this shouldn't be in the document! 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/
Processed: accepted proposal
Processing commands for [EMAIL PROTECTED]: retitle 42052 [ACCEPTED 2/4/01] /var/mail and /var/spool/mail Bug#42052: [OLD PROPOSAL] /var/mail and /var/spool/mail Changed Bug title. severity 42052 normal Bug#42052: [ACCEPTED 2/4/01] /var/mail and /var/spool/mail Severity set to `normal'. thanks Stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
Re: Policy rewrite: chaps 11-13
On Apr 02, Julian Gilbey wrote: 11.9 Statically allocated ids: If you need a statically allocated id, you must ask for a user or group id from the base system maintainer, and must not release the package until you have been allocated one. Once you have been allocated one you must make the package depend on a version of the base system with the id present in `/etc/passwd' or `/etc/group', or alternatively arrange for your package to create the user or group itself with the correct id (using `adduser') in its pre- or post-installation script (the latter is to be preferred if it is possible). What is the latter? Is it the latter alternative (or alternatively ...) or the postinst instead of the preinst? I would guess that it means postinst is preferred to preinst, but I may be wrong here. Presumably, it means that using adduser is preferred over the dependency on the correct version of base-passwd. That's the way I read the paragraph, at least. Having said that, I suspect that it's more robust to do the adduser in the postinst than in the preinst, So either interpretation seems valid and reasonable. Maybe both should be formally codified in the document... Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Bug#92589: there is no standard way to check if an init script is installed
Le 2001-04-02 14:35:06 -0300, Henrique M Holschuh écrivait : On Mon, 02 Apr 2001, Jean-Philippe Guérard wrote: However, it does not provide a standard way to check the current status of an init script. Please verify if invoke-rc.d --query (initscript) (action) in the accepted proposal #76868 is enough for your needs. invoke-rc.d is a bit different from what I am suggesting. invoke-rc.d is a level higher than update-rc.d, while check-rc.d is complementary to update-rc.d. ie you install a init script with update-rc.d, but you have no way of knowing which script is installed, and which runlevel it is installed for. invoke-rc.d will tell you if the init script is supposed to be run at the current runlevel. In other words, update-rc.d and check-rc.d are at the setup level, while invoke-rc.d is a higher level of abstraction used to run an init script, or know if it can be runned. Programs that need this information (e.g. webmin-core, ksysv, rcconf, etc.) look for information about the complete set up of the init script : + on which runlevel are these script supposed to be started or stopped (ie the full list of runlevel). + in which order will they be started or stopped. They can then display this information in a more visual way. The administrator can then easily make any necessary changes to the scripts order, runlevel, etc. invoke-rc.d (if I understand well) would give them this information only for the current runlevel, and would need to be called 2 times to do just that. check-rc.d should be a very simple script, and provide efficiently all the necessary information. Does that seem reasonnable ? Thanks! -- Jean-Philippe Guérard
Processed: reassign
Processing commands for [EMAIL PROTECTED]: reassign 90992 debian-policy Bug#90992: Relationship fields aren't allowed to be multiline Bug reassigned from package `lintian' to `debian-policy'. End of message, stopping processing here. Please contact me if you need assistance. Darren Benham (administrator, Debian Bugs database)
