[gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Doug Klima schrieb: While I haven't had much time to work on the bits, Gentopia does contain PolicyKit (though the 0.7 snapshots that appear do have some issues and you should stick to the 0.6 series). It's hopefully going to be the way forward for Gentoo to use PolicyKit. As many may know, Fedora has made this commitment and Ubuntu is starting to contribute more back and be involved a bit more. The gui project peoples along with two contributors and upstream already looked into that and at best we could use this notify feature for glsa. Gentoo is just too different to sanely work with it for full updates. Stuff like selecting useflags, outputting important changes, needed configuration updates afterwards and some more issues are plain not doable with packagekit. Though there is some work going on to get an abstraction layer for all three known package managers that work with the tree to make sure such a notify can be done. Greetz Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Markus Ullmann wrote: Doug Klima schrieb: While I haven't had much time to work on the bits, Gentopia does contain PolicyKit (though the 0.7 snapshots that appear do have some issues and you should stick to the 0.6 series). It's hopefully going to be the way forward for Gentoo to use PolicyKit. As many may know, Fedora has made this commitment and Ubuntu is starting to contribute more back and be involved a bit more. The gui project peoples along with two contributors and upstream already looked into that and at best we could use this notify feature for glsa. Gentoo is just too different to sanely work with it for full updates. Stuff like selecting useflags, outputting important changes, needed configuration updates afterwards and some more issues are plain not doable with packagekit. Though there is some work going on to get an abstraction layer for all three known package managers that work with the tree to make sure such a notify can be done. Greetz Jokey I only meant for notification purposes. Not for any updates or automatic merges. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
On 20:22 Tue 13 Nov , Markus Ullmann wrote: Doug Klima schrieb: While I haven't had much time to work on the bits, Gentopia does contain PolicyKit (though the 0.7 snapshots that appear do have some issues and you should stick to the 0.6 series). It's hopefully going to be the way forward for Gentoo to use PolicyKit. As many may know, Fedora has made this commitment and Ubuntu is starting to contribute more back and be involved a bit more. The gui project peoples along with two contributors and upstream already looked into that and at best we could use this notify feature for glsa. Gentoo is just too different to sanely work with it for full updates. Stuff like selecting useflags, outputting important changes, needed configuration updates afterwards and some more issues are plain not doable with packagekit. I'd like to talk in more detail about this with someone, but nobody on #gentoo-guis seemed to know why PackageKit wouldn't work for the simple (no USE flag changes) case. Should I try the -guis mailing list instead? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Donnie Berkholz wrote: I'd like to talk in more detail about this with someone, but nobody on #gentoo-guis seemed to know why PackageKit wouldn't work for the simple (no USE flag changes) case. Should I try the -guis mailing list instead? Looking at the current feature set of PackageKit, there's no reason we couldn't add support for Gentoo. However, PackageKit is really meant for binary distros, and some design choices really rely on that. For instance, the PackageKit tray icon will ping the backend for updates every 30 minutes or so (default value), while this is perfectly fine for apt or yum where downloading the list of available updates takes about 2 seconds (just to check the HTTP headers to see if something has changed). Obviously, this can't be kept as is for our case. Also, PackageKit has its own conventions when it comes to packages being available for one platform. Again, its model fits right with binary distros and would require some major tweaking to fit our model, but I don't think it's out of our reach. Maybe one could start writing the search backend and the install/remove backend. That would be a nice step in the right direction :) Cheers, Rémi -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Steve Long [EMAIL PROTECTED]:
Ciaran McCreesh wrote:
Steve Long [EMAIL PROTECTED] wrote:
I've always used EUID for the root check, eg:
Which is just as bad.
No, it's better for the reason given: it doesn't require login as
root. Use of ((EUID)) is also quicker.
Capabilites are the write access to the target you want to modify in
your eselect module:
test_for_root() {
# checks if the user has rights to modify /usr/bin/
[[ -w ${ROOT}/usr/bin ]] || die -q You need to be root!
}
That's how the the vim and Emacs eselect modules do it. In my opinion
the best way to check for the rights needed.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://www.faulhammer.org/
signature.asc
Description: PGP signature
[gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Ciaran McCreesh wrote:
if [[ ${UID} -ne 0 ]]; then
We've always told people not to do that. Capabilities required by
eselect modules should be tested by attempting to perform the action,
not by some arbitrary query done on UIDs or groups. Being UID 0 doesn't
mean you're allowed to do something, and not being UID 0 doesn't mean
you're not allowed to do something.
I've always used EUID for the root check, eg:
if ((EUID)); then
echo You must be root to run this script 2
exit 1
fi
This won't get round capabilities (so error status should still be checked
and the script bail with appropriate output, if it can't do something it's
supposed to) but it's sufficient for root privilege check, and is better
than UID which requires login as root. This doesn't, of course, deal with
non-root users, eg where users in group portage are allowed to carry out a
task.
You can check for that kind of thing with a writeable test, eg:
[[ -w $PORTDIR ]] || die 'Write access to portage dir required
While none of this stops you from needing to check errors, it does make it
nicer for users, imo, if scripts check early on for broader permissions
where it's appropriate.
Wrt signalling die, the correct way for a script to terminate on signal is
something like this code, taken from a SIG_INT handler:
trap INT
kill -INT $$
This ensures the parent process is correctly notified. So IOW just kill self
with the appropriate signal, ensuring any traps are cleared.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
On Thu, 08 Nov 2007 18:22:48 +
Steve Long [EMAIL PROTECTED] wrote:
if [[ ${UID} -ne 0 ]]; then
We've always told people not to do that. Capabilities required by
eselect modules should be tested by attempting to perform the
action, not by some arbitrary query done on UIDs or groups. Being
UID 0 doesn't mean you're allowed to do something, and not being
UID 0 doesn't mean you're not allowed to do something.
I've always used EUID for the root check, eg:
Which is just as bad.
This won't get round capabilities (so error status should still be
checked and the script bail with appropriate output, if it can't do
something it's supposed to) but it's sufficient for root privilege
check, and is better than UID which requires login as root. This
doesn't, of course, deal with non-root users, eg where users in group
portage are allowed to carry out a task.
Except you absolutely never should be checking for root. You should be
checking for capabilities.
You can check for that kind of thing with a writeable test, eg:
[[ -w $PORTDIR ]] || die 'Write access to portage dir required
-w is not reliable.
Wrt signalling die, the correct way for a script to terminate on
signal is something like this code, taken from a SIG_INT handler:
trap INT
kill -INT $$
This ensures the parent process is correctly notified. So IOW just
kill self with the appropriate signal, ensuring any traps are cleared.
No it isn't. When it comes to die, from bad implementations to good
implementations, the order goes: the original drobbins prefix die sucks
more than the original agriffis die, which sucks more than my original
signalling eselect die, which sucks more than the current signalling
paludis die. As time goes on we're finding better and better tricks to
work around bash's lack of exceptions; eselect is currently one
generation behind the best current known solution.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
