[arch-dev-public] [RFC] dbus cleanup
Hi guys, I'd like to propose the following change to our two dbus packages: * make libx11 an optdep in dbus * merge dbus-core into dbus * move dbus to [core] This should not have much of an effect in practice, but should make things a bit clearer and especially the naming will be more in-line with upstream and other distros. We can see that the current naming has caused some confusion as most of the packages that depend on dbus should in fact be depending on dbus-core. What do you think? I put a suggested package here: <https://dev.archlinux.org/~tomegun/>. In addition to the above changes, I dropped a dep on systemd-tools as it was causing a cycle and added a patch requested by Thomas: <https://bugs.archlinux.org/task/32902>. Cheers, Tom
On Sat, Dec 01, 2012 at 08:11:00PM +0100, Tom Gundersen wrote:
Hi guys,
I'd like to propose the following change to our two dbus packages:
* make libx11 an optdep in dbus * merge dbus-core into dbus * move dbus to [core]
This should not have much of an effect in practice, but should make things a bit clearer and especially the naming will be more in-line with upstream and other distros.
We can see that the current naming has caused some confusion as most of the packages that depend on dbus should in fact be depending on dbus-core.
What do you think?
I put a suggested package here: <https://dev.archlinux.org/~tomegun/>.
In addition to the above changes, I dropped a dep on systemd-tools as it was causing a cycle and added a patch requested by Thomas: <https://bugs.archlinux.org/task/32902>.
Cheers,
Tom
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me). I'd still like to know the history of why this was split in the first place, and not just optdep'd... d
Am 01.12.2012 20:45, schrieb Dave Reisner:
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).
I'd still like to know the history of why this was split in the first place, and not just optdep'd...
IIRC, optdep didn't exist when this was split.
On 02/12/12 09:38, Thomas Bächler wrote:
Am 01.12.2012 20:45, schrieb Dave Reisner:
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).
I'd still like to know the history of why this was split in the first place, and not just optdep'd...
IIRC, optdep didn't exist when this was split.
Turns out that optdepends did exist then. Here is the original discussion: https://mailman.archlinux.org/pipermail/arch-dev-public/2008-October/008306....
On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).
Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.
On Mon, Dec 03, 2012 at 10:07:06AM +0100, Jan de Groot wrote:
On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).
Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.
Good point, actually. I've been doing the same myself. $ grep NoExtract /etc/pacman.conf NoExtract = etc/X11/xinit/xinitrc.d/30-dbus ... d
On Mon, Dec 3, 2012 at 11:55 AM, Dave Reisner <d@falconindy.com> wrote:
On Mon, Dec 03, 2012 at 10:07:06AM +0100, Jan de Groot wrote:
On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).
Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.
Good point, actually. I've been doing the same myself.
$ grep NoExtract /etc/pacman.conf NoExtract = etc/X11/xinit/xinitrc.d/30-dbus
For the record: removing this file caused some issues, so I reinstated it. I expect it will all become redundant in the not too distant future (due to systemd --user), but let's just leave it alone for now. -t
On Mon, Dec 3, 2012 at 10:07 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).
Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.
I'll make this and the other changes and push to testing. Cheers, Tom
On 03/12/12 21:34, Tom Gundersen wrote:
On Mon, Dec 3, 2012 at 10:07 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:
While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).
Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.
I'll make this and the other changes and push to testing.
Some fun here... (1/1) removing dbus-core [######################] 100% userdel: user dbus is currently used by process 336 groupdel: cannot remove the primary group of user 'dbus' error: command failed to execute correctly Obviously nothing to be concerned about...
On Mon, Dec 3, 2012 at 12:57 PM, Allan McRae <allan@archlinux.org> wrote:
Some fun here...
(1/1) removing dbus-core [######################] 100% userdel: user dbus is currently used by process 336 groupdel: cannot remove the primary group of user 'dbus' error: command failed to execute correctly
Obviously nothing to be concerned about...
Oh, nice... I don't know why I didn't get that message. Anyway, it is not a problem. If for some reason the removal should work, then the user/group will be added back immediately by the dbus upgrade. Any suggestions on how these messages can be avoided? -t
On Dec 3, 2012 7:06 AM, "Tom Gundersen" <teg@jklm.no> wrote:
On Mon, Dec 3, 2012 at 12:57 PM, Allan McRae <allan@archlinux.org> wrote:
Some fun here...
(1/1) removing dbus-core [######################] 100% userdel: user dbus is currently used by process 336 groupdel: cannot remove the primary group of user 'dbus' error: command failed to execute correctly
Obviously nothing to be concerned about...
Oh, nice... I don't know why I didn't get that message.
Anyway, it is not a problem. If for some reason the removal should work, then the user/group will be added back immediately by the dbus upgrade.
Any suggestions on how these messages can be avoided?
-t
I do hate our filesystem upgrades since /sys was made RO and pacman tries to remove it, but perhaps we should move the dbus user there. I think as a general rule, packages in [core] should probably avoid creating users and groups to avoid problems we've seen recently.
On ma, 2012-12-03 at 13:05 +0100, Tom Gundersen wrote:
Any suggestions on how these messages can be avoided?
You can't, unless you push an update for dbus-core first...
On Dec 3, 2012 2:43 PM, "Jan de Groot" <jan@jgc.homeip.net> wrote:
On ma, 2012-12-03 at 13:05 +0100, Tom Gundersen wrote:
Any suggestions on how these messages can be avoided?
You can't, unless you push an update for dbus-core first...
There is no way to enforce that people update dbus-core first, so I think we'll just have to live with the warning. To make sure this is the last time this happens, I'll move the user/group to filesystem as Dave suggested. Cheers, Tom
participants (5)
-
Allan McRae
-
Dave Reisner
-
Jan de Groot
-
Thomas Bächler
-
Tom Gundersen