section 4.7.4 is poorly worded
4.7.4 Sharing configuration files Packages that are not tagged as conflicting with each other must not specify the same file as conffile. This is very poorly worded. The text used to read - Only packages that are tagged *conflicting* with each other may specify the same file as `conffile'. Which makes a great deal more sense.
Re: section 4.7.4 is poorly worded
On Thu, Sep 28, 2000 at 11:29:31AM -0700, Sean 'Shaleh' Perry wrote: > > 4.7.4 Sharing configuration files > > Packages that are not tagged as conflicting with each other must not specify > the same file as conffile. > > > This is very poorly worded. The text used to read - > > Only packages that are tagged *conflicting* with each other may specify the > same > file as `conffile'. > > > Which makes a great deal more sense. FWIW I understood them both just fine. I think it was changed because "may" and "must" have explicit meanings now... -- Digital Electronic Being Intended for Assassination and Nullification
Re: section 4.7.4 is poorly worded
> > FWIW I understood them both just fine. I think it was changed because "may" > and "must" have explicit meanings now... > It is rather close to reading as a double negative.
Re: section 4.7.4 is poorly worded
Sean 'Shaleh' Perry wrote: > > > 4.7.4 Sharing configuration files > > Packages that are not tagged as conflicting with each other must not specify > the same file as conffile. > > > This is very poorly worded. The text used to read - > > Only packages that are tagged *conflicting* with each other may specify the > same > file as `conffile'. > > > Which makes a great deal more sense. Or what about: Packages which specify the same file as `conffile' must be tagged as *conflicting* with each other. Which loses the double-negative, and retains the strong _must_ without becoming impenetrable. Regards, Andrew McMillan. -- _ Andrew McMillan, e-mail: [EMAIL PROTECTED] Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
Re: section 4.7.4 is poorly worded
On Thu, Sep 28, 2000 at 09:33:44PM +0200, Josip Rodin wrote: > FWIW I understood them both just fine. I think it was changed because "may" > and "must" have explicit meanings now... I was able to understand the first only after reading it over a few times. The second was immediately clear. No professional editor would allow the first version to be published. If we've redefined the dictionary meanings of "may" and "must", then maybe we should look for yet another word to use in this case. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into | this .signature file.
Re: section 4.7.4 is poorly worded
> > Or what about: > > Packages which specify the same file as `conffile' must be tagged as > *conflicting* with each other. > > > Which loses the double-negative, and retains the strong _must_ without > becoming impenetrable. > I like this text. Perhaps it should read "file as a 'conffile'" though.
Bug#72335: PROPOSED] Optional build-arch and build-indep targets for debian/rules
On 2925T152912+0200, Roman Hodek wrote: > A patch to dpkg-buildpackage is sufficient, as the daemons just call > dpkg-buildpackage -B. Ok. > Does it make sense to allow one 'build-*' target without the other? If > a package can utilize the separation, it needs both anyway. In extreme > cases, one of the targets still can be empty. But requiring both makes > it easier to test for them. You're right. I'm too tired to fix the diff now, and I'm going away for the weekend. Anybody willing to fix the diff for me? :-) > But besides this, I support this proposal. Is that a second? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Preparing Debian for using capabilities: file ownership.
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> Or, put another way, we're going to have to re-write a lot Raul> of administrative docs to adapt to a capabilities-based Raul> security setup. And then we'll have to do it again for Raul> MAC. ;-) or should that be :-( Raul> [Also: both have extra baggage, but MAC+capabilities looks Raul> like something safer to switch over to than capabilities Raul> without MAC.] Where can I find out more about MAC? MAC is a completely new acronym to me... >> - what is the current status of capabilities in Linux? Last I heard, >> it was so limited that it was next to useless. I hope this has/will >> change. Raul> They're implemented in 2.4, but they're not ready for prime Raul> time. The set of capabilities may change, and ext2fs Raul> doesn't let you do the capability analog to setuid (nor the Raul> inverse -- where capabilities are supressed). Will it be possible to limit individual processes access to individual files? I have a good reason for wanting to do this, but so far, all I can tell is that the list of capabilities is fixed/hard-coded in the kernel and cannot be changed. Raul> Not very practical. Raul> kernel change time != package install time. Raul> Basically, we'd be committing to do a complete sweep of the file Raul> system every time the kernel booted. [Perhaps optimize this by Raul> marking each partition with a stamp indicating what kernel Raul> has swept the partition?] My guess is that supporting both systems could get very messy, very quickly. However, I think supporting both systems might be essential, so that people can get use to the completely different way in which things are done, which-out being "forced" into the change. I can't say much more then that right now until I get a chance to play around with some of this stuff myself. Perhaps enhancing suidregister to support capabilities might be a good first step. -- Brian May <[EMAIL PROTECTED]>
