From: Stefan Schweizer <sschweizer@gmail.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Bug#286040: please allow permissions.d to follow symlinks
Date: Sat, 18 Dec 2004 09:48:00 +0000 [thread overview]
Message-ID: <e79639220412180148fdb1836@mail.gmail.com> (raw)
In-Reply-To: <20041217083115.GA4050@wonderland.linux.it>
On Sat, 18 Dec 2004 05:21:11 +0100, martin f krafft <madduck@madduck.net> wrote:
> also sprach Greg KH <greg@kroah.com> [2004.12.18.0404 +0100]:
> > So, on what "technological level" do you rank the current crop of
> > distros (and by "crop" I mean ones that have had a release.)
>
> I do not rank. Fact is that I will see whether Debian can continue
> to use permissions.d and provide the symlink following I initially
> requested, simply because I consider policy-based approaches to be
> important. Without going comparative, this is going to put Debian on
> a different level than other distros which go ahead to dump
> permissions.d *with respect to* udev permission handling. This will
> make it difficult to converge on a common set of rules.
>
If you look at the code you will see that removing permissions.d and
keeping everything in rules.d will make the code more lightweight,
make udevstart faster, and therefore startup for the udev users
faster.
> You told me at Sucon '04 that (one of) your main beef(s) with Debian
> is that we do not make patches with improvements available upstream.
> I promised you I would look into this and try to improve the
> situation. However, reading the archives, talking to Marco, and
> looking at bugs, it seems to me that we are banging our heads
> against the wall that you hold up, that you simply do not want our
> patches.
I think every maintainer does not just merge patches, but thinks about
what they do, and maybe better solutions, how the goal could be
achieved. Thing is, that patches, which are not send upstream never
get discussed or reviewed and therefore have a much less code quality.
> A bystander might conclude from this very case we are
> discussing here that you are now crippling upstream just to make
> sure it will differ from Debian.
This is a prejudice against gregkh, what should he benefit from it? We
are in a open source world here, not in a economic, where you have to
compete. We will try to find a good solution for this, which is
acceptible for all parties.
> What is the benefit of merging permissions in with rules that
> identify and name devices?
>
It makes it just easier for the user. He/She does not have to look in
2 different locations, he does not need to know the permissions.d
syntax, he does not need to know about this extra file, he has one
unified configuration interface.
Its easier, lightweighter, faster ... just think about it once more.
> If you answered that, please also think about the reasons why Fedora
> uses /etc/sysconfig (and Gentoo probably does something similar).
Gentoo uses /etc/conf.d for system init script configuration. But we
have one unified configuration interface there, it is all
CONFNAME="option", and not a different interface like the one in the
permissions.d file, as that would confuse users.
> > And why wouldn't all distros benifit from such a set of unified rules?
>
> I am not at all denying this.
> How to unify rules when there are differences in opinions?
>
We should sort out our differences, and come to a decision, that is
acceptable for everybody. It shouldnt be that hard to have one
configuration interface in all distros and not one for every distro.
And after all I think even debian as the most widespread free
distribution should hear why the udev maintainer denies something and
not just make their own "debian-udev".
Kind regards,
Stefan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2004-12-18 9:48 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-17 8:31 Bug#286040: please allow permissions.d to follow symlinks Marco d'Itri
2004-12-17 10:11 ` Stefan Schweizer
2004-12-17 10:48 ` martin f krafft
2004-12-17 13:24 ` Kay Sievers
2004-12-17 13:38 ` martin f krafft
2004-12-17 13:40 ` Marco d'Itri
2004-12-17 13:45 ` Kay Sievers
2004-12-17 13:47 ` Kay Sievers
2004-12-17 13:49 ` Marco d'Itri
2004-12-17 13:56 ` Kay Sievers
2004-12-17 13:58 ` martin f krafft
2004-12-17 14:13 ` Kay Sievers
2004-12-17 14:19 ` martin f krafft
2004-12-17 14:20 ` Kay Sievers
2004-12-17 14:35 ` martin f krafft
2004-12-17 14:36 ` Stefan Schweizer
2004-12-17 14:42 ` martin f krafft
2004-12-17 14:45 ` Kay Sievers
2004-12-17 14:52 ` martin f krafft
2004-12-17 15:50 ` Greg KH
2004-12-17 16:14 ` martin f krafft
2004-12-17 16:45 ` Greg KH
2004-12-17 17:10 ` martin f krafft
2004-12-17 17:45 ` Stefan Schweizer
2004-12-17 18:33 ` Greg KH
2004-12-17 18:40 ` martin f krafft
2004-12-17 23:25 ` Kay Sievers
2004-12-17 23:41 ` martin f krafft
2004-12-18 0:25 ` Lindsay Haisley
2004-12-18 0:53 ` martin f krafft
2004-12-18 1:18 ` martin f krafft
2004-12-18 3:04 ` Greg KH
2004-12-18 4:18 ` Lindsay Haisley
2004-12-18 4:21 ` martin f krafft
2004-12-18 9:48 ` Stefan Schweizer [this message]
2004-12-18 12:33 ` Tobias Klauser
2004-12-18 13:04 ` Marco d'Itri
2004-12-19 4:34 ` Randy.Dunlap
2004-12-20 9:39 ` martin f krafft
2004-12-20 17:56 ` Lindsay Haisley
2004-12-20 18:04 ` martin f krafft
2004-12-20 19:05 ` Lindsay Haisley
2004-12-21 8:04 ` martin f krafft
2004-12-21 16:11 ` Lindsay Haisley
2004-12-21 16:31 ` Lindsay Haisley
2004-12-21 16:38 ` martin f krafft
2004-12-21 16:48 ` Tobias Klauser
2004-12-21 16:54 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e79639220412180148fdb1836@mail.gmail.com \
--to=sschweizer@gmail.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).