On 3/8/07, Chris Frey <[EMAIL PROTECTED]> wrote:
>
> This doesn't seem to be portable on systems such as Debian stable, so
> in the best case for this feature, it will still be limited to RPM
> installs on systems that support it.
I would say that, much like the udev rules, we could simply rename the
file or whatnot so that it's only applicable to a RPM; well, I think
we mean Red Hat/Fedora) system. From what I can tell this subsytem has
been in place for quite some time -- it used to be 'hotplug', but
apparently that went the way of the dodo with more recent releases.
As for calling it non-portable, that might be a bit much as it's an
ancillary script, not part of the main codeball. Since it would never
be installed by a classic "make install" I don't see a problem. DEB
files are welcome to do what they want.
> Setting up a barry group is more portable with all versions of udev.
While I understand this idea fully, I don't think it jives with the
landscape of a RH/Fedora system. Personally I don't want yet one more
group cluttering up my system when we can do it a cleaner way using
the builtin subsytem; having a whole group for one device is not
desireable.
I liken a BB device to any random USB device that I plug in - my
camera, USB thumb drive, you name it -- I believe dynamically changing
ownership a much better approach. But, this leads into...
> In desktop systems, this is most likely to be the case, but in the case
> where you're running a service, perhaps a daemon that wants to access
> the Blackberry, or if you're logging in remotely, I find that group
> based permissions works better. Of course, the udev script to be
> modified to set the user to console owner and group to "barry", so
> this could be worked around.
Given what I know people do (which, granted is solely from my
experience and contacts) when it comes to a device like a BB they
*will* be logged in as the console user. This device is user-centric,
it will be with the user ("crackberry") almost always. They want to
plug in the device, data sync or use USB mass storage (or maybe the
modem?) unplug and go. If a particular service should happen to appear
on the landscape for this (what would it be?) then worry about
tackling it then - it may never appear for all we know.
If you look at the default setup
(/etc/security/console.perms.d/50-default.perms) on a Fedora system
you'll see nearly everything is handled this way - bluetooth adapters,
scanners, palm pilots (my Treo650 works fine without a 'treo' group)
and on and on. The system is designed to adapt to the logged in user
rather than beating it to death with groups - these are
desktop-user-centric devices.
My $0.02, I don't want a barry group on RH/Fedora systems - I feel
it's unnecessary. But that doesn't stop the DEB world from doing it!
:) That's kinda the whole point of packaging, take the generic and
adapt it to the specific.
-te
--
some live, some die
in the way of the samurai
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
