Skip to main content
Topic: Replace dbus-runscripts with gremlins/dbus-runit? (Read 2035 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Replace dbus-runscripts with gremlins/dbus-runit?

Code: [Select]
Replace dbus-runscripts with gremlins/dbus-runit?

This is in gremlins and dbus-runscripts is in world
Should we or shouldn't we do this, and why?

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #1
Code: [Select]
Replace dbus-runscripts with gremlins/dbus-runit?

This is in gremlins and dbus-runscripts is in world
Should we or shouldn't we do this, and why?

Artix has adopted repository structure from arch, where [testing] is meant for packages from [core] and [extra].
In Artix it is [gremlins] for [system] and [world].

There was an update on runit packages in testing (gremlins) repository.

I don`t use runit, so i don`t know if it is safe update or not.

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #2
yes, but dbus-runscripts. if I am not mistaken, is used without the use of runit.

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #3
yes, but dbus-runscripts. if I am not mistaken, is used without the use of runit.

I see it as part of runit support package which provide init script for runit.

I might also be wrong, lets wait until someone involved reply.

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #4
Hello, sorry for late reply.

Currently, all service script packages (both OpenRC and runit) are in the process of decoupling to its own PKGBUILD, in the old scheme we combine all script in one PKGBUILD. This is no longer the case, so I'm in the process of migrating all service packages.

As for the naming scheme, as of now I decided to change -runscripts to -runit because in some service scripts the commands are runit-exclusive (e.g. chpst, not available in s6), and when we decide to add s6 as a supported init, we'll see what we can do later.

Code: [Select]
Replace dbus-runscripts with gremlins/dbus-runit?

Should we or shouldn't we do this, and why?

Depends, do you use runit?

I don`t use runit, so i don`t know if it is safe update or not.

I don't know why and I won't ask why you're installing it if you're not even using runit, but yes it should be safe to update. Only the name changed, not the structure (still /etc/sv)as of 20180226, it's moved to /etc/runit/sv
now only the dinit guy in artix

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #5
I don't know why and I won't ask why you're installing it if you're not even using runit, but yes it should be safe to update. Only the name changed, not the structure (still /etc/sv)as of 20180226, it's moved to /etc/runit/sv

It is not a matter of installing but there are occasions which dbus-runscript was installed without runit and the upgrade asks to replace it.  It seems to me from what you have described in the runit thread that those who are not using runit (as init or supervision) should not replace it.

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #6
It is not a matter of installing but there are occasions which dbus-runscript was installed without runit and the upgrade asks to replace it.

Because of how I structured the packages, while dbus-runit service can be installed without runit, it shouldn't be pulled unless one explicitly installed it or installed another runit service pkg which depends on dbus-runit.

It seems to me from what you have described in the runit thread that those who are not using runit (as init or supervision) should not replace it.

I'm sure nothing in my post over there suggest that the packages shouldn't be upgraded if one doesn't use runit.
now only the dinit guy in artix

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #7
I think we are not in sync on this.
It is not a matter of installing anything.  Installations that have nothing in terms of runit have dbus-runscripts.
When trying to do a regular update "pacman -Su" it asks to replace dbus-runscripts with dbus-runit

And the answer seems to be no, but maybe this shouldn't be happening unless someone is installing runit or already has runit installed.  That is what the question really is about.  Why is pacman on a normal update asks to replace dbus-runscripts.


Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #8
I think we are not in sync on this.
It is not a matter of installing anything.  Installations that have nothing in terms of runit have dbus-runscripts.
When trying to do a regular update "pacman -Su" it asks to replace dbus-runscripts with dbus-runit

Of course it has something to do with "installing", or more like, something that pulls dbus-runscripts as a dependency into your installation, pacman -Su requests to replace dbus-runscripts with dbus-runit because dbus-runscripts is installed in your system. If dbus-runscripts is not installed in your system, then there will be no questions about replacing anything, at all.
now only the dinit guy in artix

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #9
I don't really understand what is so hard to communicate but here is the fact that I find unaccepatable.

A USER has installed artix, let's say some common scenario, with sddm and lxqt just like in the installer live.
Because of SDDM dbus-runscripts is installed.  Dbus runscripts incorporates 2 scripts, while dbus-runit just eliminates the one, which I am no authority to presume it is not really needed by sddm.
THE USER does not want runit as init or supervisor, just keeps the OEM sysvinit/openrc.

THE USER IS ETERNALLY  subjected to when updating {pacman -Suy} to have to deny the replacement of dbus-runscripts by dbus-runit.  For ever this will be the first thing pacman will ask THE USER.


I find this an unacceptable way to be doing things and after all these days it is still going on!

@konimex:   it is OK, if you don't want runit just say NO!

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #10
I don't really understand what is so hard to communicate but here is the fact that I find unaccepatable.

A USER has installed artix, let's say some common scenario, with sddm and lxqt just like in the installer live.
Because of SDDM dbus-runscripts is installed.  Dbus runscripts incorporates 2 scripts, while dbus-runit just eliminates the one, which I am no authority to presume it is not really needed by sddm.
THE USER does not want runit as init or supervisor, just keeps the OEM sysvinit/openrc.

THE USER IS ETERNALLY  subjected to when updating {pacman -Suy} to have to deny the replacement of dbus-runscripts by dbus-runit.  For ever this will be the first thing pacman will ask THE USER.


I find this an unacceptable way to be doing things and after all these days it is still going on!

Look, here is a basic package management lesson.

A package should not be installed unless:
1. It is installed explicitly.
2. It is pulled as a dependency by another package.

There is no chance that dbus-runscripts will be installed a user explicitly installs it.

Your scenario have a fatal flaw:

A user types pacman -S sddm, with Artix/Arch packaging system (see pacman -Si sddm for its dependencies or its PKGBUILD), pacman will never, ever ask for dbus-runscripts. Unless you installed sddm-runscripts, which is NOT a dependency of sddm and if you use OpenRC exclusively, can be safely uninstalled.

Look, pull up a fresh Artix instance in a VM, install SDDM (not sddm-runscripts), show me the part where somehow dbus-runscripts is installed.

In case you still don't get it. "pacman -R dbus-runscripts" and I'll pretend this post never happened.

@konimex:   it is OK, if you don't want runit just say NO!
Look at the slogan for Artix, "your Arch, your init". I don't care what init you use, really. Even if you somehow installed systemd and managed to run it concurrently with OpenRC in Artix.
now only the dinit guy in artix

Re: Replace dbus-runscripts with gremlins/dbus-runit?

Reply #11
Ok, sorry, I thought when I first looked at this and why it was installed I thought it was a dependency of sddm not sddm-runscripts ...   I must be going blind.
Now it makes sense why I keep asking why this is going on and you not finding it strange.
I must have explicitly installed sddm-runscripts then!