From: sgn <sgn@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [WIP] wlroots: update to 0.12.0
Date: Wed, 11 Nov 2020 01:34:47 +0100 [thread overview]
Message-ID: <20201111003447.FF6iInvdl7oNy9vhWUlnma1E62sjK8limaskcbVhzSE@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-26224@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
New comment by sgn on void-packages repository
https://github.com/void-linux/void-packages/pull/26224#issuecomment-725041788
Comment:
> I know I suggested renaming the `elogind` build option to `setuid` to achieve the default behavior, but looking at this propagating everywhere, I really think this is an inappropriate abuse of a build option.
`xorg-server` also has `elogind` build option, with that option on, `setsuid` is dropped, too. So, I think *the* convention is use `elogind`.
p/s: I have no opinion, whatsoever, just want to point out current practice. I still live in xorg land.
>
> After package installation, XBPS does not track file permissions, so the user can always set or clear the setuid bit depending on desired behavior. This gets a little annoying if updates toggle the bit, but is it any more annoying than having to rebuild the package after every update with some build option just to toggle the bit for you? I submit that it is _less_ annoying, and users can always hold the package to avoid being surprised if they really want.
>
> Either the binaries should default to setuid root or they should not; this is a question for regular Wayland users (one of which I am not) to hash out. But I strongly suggest the build option be dropped.
next prev parent reply other threads:[~2020-11-11 0:34 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-08 15:36 [PR PATCH] " ofiala-a51
2020-11-08 15:46 ` ericonr
2020-11-08 17:04 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-08 17:16 ` ofiala-a51
2020-11-08 17:46 ` [WIP] " ericonr
2020-11-08 17:53 ` ofiala-a51
2020-11-08 18:14 ` ofiala-a51
2020-11-08 18:21 ` jbeich
2020-11-08 18:22 ` jbeich
2020-11-08 18:28 ` ofiala-a51
2020-11-08 18:48 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-08 19:05 ` ofiala-a51
2020-11-08 19:43 ` ofiala-a51
2020-11-10 15:23 ` ifreund
2020-11-10 16:45 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-10 16:48 ` ofiala-a51
2020-11-10 16:53 ` ofiala-a51
2020-11-10 16:54 ` ofiala-a51
2020-11-10 18:21 ` [PR REVIEW] " ericonr
2020-11-10 18:29 ` ericonr
2020-11-10 18:30 ` [PR REVIEW] " ahesford
2020-11-10 18:34 ` ericonr
2020-11-10 19:53 ` st3r4g
2020-11-10 19:53 ` st3r4g
2020-11-10 19:54 ` st3r4g
2020-11-10 20:02 ` st3r4g
2020-11-10 20:04 ` st3r4g
2020-11-10 20:12 ` st3r4g
2020-11-10 20:38 ` st3r4g
2020-11-10 20:39 ` st3r4g
2020-11-10 20:55 ` st3r4g
2020-11-10 21:08 ` ifreund
2020-11-10 21:25 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-10 21:28 ` [PR REVIEW] " ofiala-a51
2020-11-10 21:28 ` ofiala-a51
2020-11-10 22:04 ` [PR REVIEW] " ifreund
2020-11-10 22:04 ` ifreund
2020-11-10 22:39 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-10 22:40 ` [PR REVIEW] " ofiala-a51
2020-11-10 22:40 ` ofiala-a51
2020-11-10 23:22 ` ahesford
2020-11-10 23:23 ` st3r4g
2020-11-10 23:23 ` st3r4g
2020-11-10 23:25 ` st3r4g
2020-11-10 23:38 ` [PR REVIEW] " st3r4g
2020-11-10 23:40 ` ofiala-a51
2020-11-10 23:52 ` ifreund
2020-11-10 23:54 ` ifreund
2020-11-10 23:57 ` [PR REVIEW] " ofiala-a51
2020-11-11 0:02 ` ifreund
2020-11-11 0:03 ` sgn
2020-11-11 0:08 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-11 0:08 ` [PR REVIEW] " ofiala-a51
2020-11-11 0:34 ` sgn [this message]
2020-11-11 0:55 ` travankor
2020-11-11 1:13 ` ericonr
2020-11-11 1:24 ` [PR REVIEW] " ofiala-a51
2020-11-11 1:44 ` travankor
2020-11-11 14:03 ` ofiala-a51
2020-11-11 14:14 ` ahesford
2020-11-11 14:52 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-11 15:43 ` ofiala-a51
2020-11-12 22:28 ` ericonr
2020-11-13 10:19 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-13 10:20 ` ofiala-a51
2020-11-17 3:14 ` ericonr
2020-11-17 3:14 ` ericonr
2020-11-17 3:39 ` ericonr
2020-11-17 3:56 ` ericonr
2020-11-17 13:10 ` ericonr
2020-11-17 13:11 ` ericonr
2020-11-17 13:17 ` ericonr
2020-11-17 14:11 ` ericonr
2020-11-17 15:06 ` ericonr
2020-11-17 15:13 ` ericonr
2020-11-17 15:36 ` ericonr
2020-11-17 18:28 ` ericonr
2020-11-18 14:49 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-18 14:51 ` ofiala-a51
2020-11-18 15:02 ` ofiala-a51
2020-11-18 15:04 ` ofiala-a51
2020-11-19 13:12 ` ericonr
2020-11-19 17:00 ` [PR PATCH] [Updated] " ofiala-a51
2020-11-20 21:50 ` [PR PATCH] [Merged]: " ericonr
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=20201111003447.FF6iInvdl7oNy9vhWUlnma1E62sjK8limaskcbVhzSE@z \
--to=sgn@users.noreply.github.com \
--cc=ml@inbox.vuxu.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).