Re: Bug#178251: slang: don't do a dh_testroot in clean
Richard Braakman [EMAIL PROTECTED] writes: On Thu, Mar 20, 2003 at 11:10:58PM +0100, Bill Allombert wrote: Why? because they support building packages as root when dh_testroot can solve a lot of headache ? Ye gods! Removing dh_testroot does not break the build-as-root case! What does dh_testroot solve in the clean target? Seriously. I've never understood why people put it in. It gives a slightly more understandable error message, that's all. Personally, I think someone who is entitled to become root should be able to figure out what he has to do on Permission denied errors. -- Robbe pgpAwxFYhwaVU.pgp Description: PGP signature
Re: Bug#178251: slang: don't do a dh_testroot in clean
Chris Waters [EMAIL PROTECTED] writes: I think things are fine the way they are, I think what you're suggesting would be a lot of work, I see no tangible benefits, therefore I oppose the idea. The benefit is 9 characters less typing per rebuild cycle per person. There were patterns put into virus scanners for less lost manpower than this. Whether individual packages should be bugged is debatable, but the practise should definitely be stricken from dh_make and company. -- Robbe pgpGmuLHODZBv.pgp Description: PGP signature
Bug#160827: syntax of the maintainer name in the Maintainer: field
Clint Adams [EMAIL PROTECTED] writes: Preserving would be useful if there were a lot of users or programs taking the content of the maintainer field and stuffing it into a To header.[...] One program that does that is jennifer (of katie fame). True. It could get away with tossing everything outside angulars or inside brackets, though. The address can be mandated to stay 7bit for now. -- Robbe
Bug#167422: general: files in /usr/share should be world-readable
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: This is incorrect. /usr/share is intended to be shared between cooperating systems, but cooperating systems' root users might well have secrets that they want to conveniently share. /usr/share is not appropriate for that, as it is the OS's playground (and I can't see any use for the OS installing secrets there). For site-specific secrets /usr/local/share is a better choice. -- Robbe
Re: build-deps non non-US does not implies archiving in non-US?
Sven Luther [EMAIL PROTECTED] writes: All packages have to be buildable with the current release. And this does not include non-us if you happen to be in the us. Nope, you may freely download from non-us.debian.org, even if you're currently in the USofA. -- Robbe signature.ng Description: PGP signature
Bug#60979: What /etc/init.d/xxx restart does?
Bill Allombert [EMAIL PROTECTED] writes: I feel it is very important every init script behave the same. However the wording of section 10.3.2 is confusing: The init.d scripts should ensure that they will behave sensibly if invoked with start when the service is already running, or with stop when it isn't, and that they don't kill unfortunately-named user processes. The best way to achieve this is usually to use start-stop-daemon. What mean 'behaving sensibly' ? Starting and stopping a service should be idempotent, i.e. further attempts should silently succeed. You are right that the above paragraph could convey this better. If you have a suggestion, file another bug with the patch. But what became of the bug's initial issue? Changing of the semantics of restart was shot down, but what about adding a maybe-restart action for logrotate, postinst, etc.? I called it condrestart in one of my packages. -- Robbe
Re: Bug#132767: acknowledged by developer (Reviewing policy bugs)
Manoj Srivastava [EMAIL PROTECTED] writes: Mail setups that do not understand MIME are antiquated to the point that most email must be hard to deal with. Fine by me. Robbe But you were using characters outside ASCII as well, so one Robbe needs tools to turn them from UTF8 gibberish into something Robbe readable. I see. Anything your parochial. limited, MUA can't render is gibberish. Obviously, since I'm not able to interpret raw UTF8 sequences beyond U+007F in my head. You X-Face is surely to people without the right help -- as is my GPG signature. The difference being that these are add-ons, not important parts of the message itself. So what's your stand now? Do I need to get tools to understand UTF8 to be able to follow debian-policy or not? And yes, my email do tend to have characters beyond plain ascii 7, as the headers for my mails state. I haven't done an analysis, but actually I've seen few mails from you that contained non-ASCII characters in important positions. The referenced one was one of those few, so I took it as the reason to ask. Robbe One can't use this unicode hyphen and have getopt understand Robbe it. You were pasting a commandline that didn't work. Incorrect Robbe enough for you? A) I was not pasting a command line, In another mail you said you did. Anyway, s/pasting/writing/ b) you would have to selectively excise and edit my email before sticking it in (like, my signature would confuse apt, I would think), Sure. My MUA is advanced enough to allow that. Your point was? and c) it was written to address people who could exercise a modicum of common sense, really. I am sorry if it was misadressed in your case. If you read my mail, you'll certainly notice that I knew what you meant. I just pointed out that you gratuitously used an non-ASCII character instead of the (IMO more correct) ASCII equivalent. (I shall not use the fact that I was pasting the output of man, and that the utf-8 was not delibrate, as an argument, since I make no bones about not sticking to ascii in my emails) I'm going to run with this as a kind of yes answer to my UTF8 mandatory question, since you're obviously bent upon taking my writing as useless flamage, and therefore a straight answer is improbable. -- Robbe signature.ng Description: PGP signature
Re: Bug#132767: acknowledged by developer (Reviewing policy bugs)
Manoj Srivastava [EMAIL PROTECTED] writes: Robbe Is Unicode manadatory now? (You somewhat incorrecly used Robbe U+2010, hyphen, in that mail.) Mandatory? mandated by whom? Obviously MIME is mandatory for participation in policy process I infer from your Fix your MUA comment. But you were using characters outside ASCII as well, so one needs tools to turn them from UTF8 gibberish into something readable. And, pray tell, why exactly is it incorrect? One can't use this unicode hyphen and have getopt understand it. You were pasting a commandline that didn't work. Incorrect enough for you? I see a hyphen. Hyphen != Hyphen-Minus although they probably look exactly or nearly exactly alike. -- Robbe signature.ng Description: PGP signature
Re: Bug#132767: acknowledged by developer (Reviewing policy bugs)
Manoj Srivastava [EMAIL PROTECTED] writes: shite? Fix your own darned MUA. Is Unicode manadatory now? (You somewhat incorrecly used U+2010, hyphen, in that mail.) -- Robbe signature.ng Description: PGP signature
Re: Java policy
Ola Lundqvist [EMAIL PROTECTED] writes: There are some things that might want to be added before it becomes truly official. See the policy at: http://www.debian.org/doc/packaging-manuals/java-policy/ * gcj and how to handle that (should it be mentioned at all?). I don't have the specifics to that handy. URL? * should all virtual machines that provides a java2 virtual machine also provide a 'java2' command (not 'java'). As the originator of this request, I'd be happy to have an official version without this and punt this to the next version. * How to handle jar dependencies? Should there be some kind of mechanism for that? Since nobody is currently on top of that, I'd suggest leaving it out, too. -- Robbe signature.ng Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Branden Robinson [EMAIL PROTECTED] writes: If they're not in /usr, they're off-limits. As are the POSIX utilities for determining whether or not they're in /usr. What POSIX utilities do you mean? (I don't have that standard handy.) SUSv[23] provide command -v as the standard way. Debian's ash and bash have this as a builtin, zsh (e.g) does not, and we neither have it in /bin nor /usr/bin. Further, /bin/bash is available and provides both type and test as builtins. Bad news for any Debian port that wants to use ash as its Essential shell, then. $ ash -c type test test is a shell builtin ash and bash are AFAIK the only shells in /bin. However, in the course of researching the problem I encountered our current handling of the disction between executables in /usr and /, which appears to be driven wholly by personal fiat and/or accident. I think the availablity of minimal^Wessential^Wwhatever system functionality is too important to be left to fiat, and that we should document the undocumented assumptions and reasoning that have led us to the status quo, so that we can collectively make better decisions in the future. What guidelines, in addition to FHS 3.1, are you actually proposing? -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gnome-libs-data: /etc/mime-magic.dat
Can a file that is not human readable (editable) be a conffile? gnome-libs-data declares /etc/mime-magic.dat (which is some kind of binary database generated from the textual conffile /etc/mime-magic) as such. The maintainer thinks this is correct -- I obviously don't. I'm bringing this up on -policy because I couldn't find explicit text about this in current policy. Maybe this should be clarified. My view is that stuff which the admin will (directly) edit should be a conffile. In this particular case, mime-magic.dat shouldn't be in the package at all, but rather (re)generated in the postinst. Just like the aliases databases of various mailers. -- Robbe signature.ng Description: PGP signature
mandate ldconfig -X?
I propose that instead of calling ldconfig, maintainer scripts of packages containing shared libraries should call ldconfig -X. Background: ldconfig has two purposes: 1. For each shared library, create/update a symbolic link from the library's soname to the library file. The link is only changed if it was broken/non-existing before, or the library in question has a higher version than the current destination of the link. 2. Update the locations of shared libraries in /etc/ld.so.cache Per default, ldconfig will execute both actions. Rationale: On a Debian system, the first point is moot, because library packages will include the appropriate symlink already as per policy. The second action is generally useful. ldconfig -X will do just that, and omit the first. Why should we not commit the first action anyway? For one, it is unnecessary, and wastes time. But more importantly, the Hurd has no ld.so.cache, which kills reason 2 on this platform. Debian GNU/Hurd systems also don't have reason 1, so there is currently no real ldconfig program on the Hurd. Rather than writing a program that's completely pointless, I'd rather we called ldconfig correcly, i.e. with the -X parameter. ldconfig -X will just do nothing on the Hurd. Comments appreciated. If no flaws are found in my logic, I'll submit a proposal. -- Robbe signature.ng Description: PGP signature
