Project

General

Profile

Bug #2618

dbus already exists (1.12.16-3.nonsystemd1)

nona - about 4 years ago - . Updated over 3 years ago.

Status:
not-a-bug
Priority:
bug
Assignee:
% Done:

0%


Description

Hi, when installing dbus-1.12.16-3.nonsystemd1, I get an error about the file already existing. I am using OpenRC with the nonsystemd repository. I checked the files in the package and in my system, and besides some small differences, they seem to do the same. Thanks.

History

#1

Updated by nona about 4 years ago

Sorry its /etc/runlevels/default/dbus

#2

Updated by bill-auger almost 4 years ago

  • Assignee set to Megver83
  • Status changed from unconfirmed to confirmed

there was a bug report today on the mailing list that is possibly related to this recent change

# pacman -Syu
nonsystemd/dbus  1.12.16-2.nonsystemd2  1.12.16-5.nonsystemd1    0.01 MiB

error: failed to commit transaction (conflicting files)
dbus: /etc/runlevels/default/dbus exists in filesystem
Errors occurred, no packages were upgraded.

https://lists.parabola.nu/pipermail/assist/2020-April/001477.html

#3

Updated by Megver83 over 3 years ago

  • Status changed from confirmed to not-a-bug

this has to be a bad joke

just do `rc-update del dbus default` and install dbus, or do `pacman -S --overwrite etc/runlevels/default/dbus dbus`

bill-auger what happened with the "invalid" state? it disappeared some time ago, was it replaced with not-a-bug?

#4

Updated by bill-auger over 3 years ago

yes i changed the label, and add some more - the generic 'invalid'
was essentially split into 'not-a-bug' for bugs, and 'wont-fix' for
feature requests - similarly for the generic 'open', vs. the more
meaningful replacements: 'unconfirmed' and 'confirmed'

it is all explained on this wiki page
https://wiki.parabola.nu/DeveloperWiki:Web_Admin

"Note that the 'unconfirmed' and 'confirmed' states for the Bugs
tracker class are analogous to the single 'open' state for the
Features tracker class; and the 'not-a-bug' state for the Bugs
tracker class is analogous to the 'wont-fix' state for the Features
tracker class."

#5

Updated by nona over 3 years ago

Megver83 wrote:

this has to be a bad joke

You have a strange sense of humour.

just do `rc-update del dbus default` and install dbus, or do `pacman -S --overwrite etc/runlevels/default/dbus dbus`

Trying to upgrade a package and being unable to do it... is not a bug? Should the file be replaced automatically? I mean, I did not modify that file (or even knew it existed) prior to noticing this.

This work around surely works... as much as mine. I think that users should not be concerned about replacing a service that comes with a package, right?

#6

Updated by Megver83 over 3 years ago

nona wrote:

This work around surely works... as much as mine. I think that users should not be concerned about replacing a service that comes with a package, right?

I don't even know how did you got that file to conflict dbus. If rc-update del doesn't work, then pacman -S --overwrite will just solve your problem. Easy. OpenRC just creates symlinks inside /etc/runlevels, and dbus package comes with its symlink already so that users don't have to manually enable it as it is a core service.

#7

Updated by bill-auger over 3 years ago

that smells wrong to me - if that is the problem, then i say this
is-a-bug - the package should not install that symlink - all service
packages i have seen, install the service file to
/usr/lib/systemd/system/; and require the manual step upon the user
to enable the service - that is why parabolaiso must chroot into the
live system and enable services - and that is why the install guide
has explicit instructions to enable networkmanager

if it is possible, the package could enable the service in the proper
way, in a pacman install hook, and disable the service in an
uninstall hook - if pacman hooks can not do that, then it should print
a message, reminding the user to enable it

for one thing, that would actually enable the service as soon as the
package is installed, rather than being dormant until the next reboot

i wonder, do the essential systemd services play that same trick?

#8

Updated by bill-auger over 3 years ago

in any case, to answer nona, i must believe that the user had done something wrong - that is probably how megver was thinking, this is not a real bug -

how did that symlink get there, if the package was not installed yet? - that should not be possible - unless the user, put a symlink there with `ln`, pointing at nothing; because the proper way to enable a service (`rc-update`) would not create that symlink if the service was not installed

from the mailing list:

# pacman -S dbus
Package (1)      Old Version            New Version            Net Change
nonsystemd/dbus  1.12.16-2.nonsystemd2  1.12.16-5.nonsystemd1    0.01 MiB
error: failed to commit transaction (conflicting files)
dbus: /etc/runlevels/default/dbus exists in filesystem

that indicates that the installed 'dbus' packages did not own the file: /etc/runlevels/default/dbus; and that the file was added by the user, then the new 'dbus' package wants to own that file - if that is the case, then this will require manual intervention by everyone who has 'dbus' installed and enabled currently

if that is the case, we should post a news alert about it - but i think there is a better way to handle it - it doesnt seem right, to have the package own that symlink

#9

Updated by nona over 3 years ago

bill-auger wrote:

in any case, to answer nona, i must believe that the user had done something wrong - that is probably how megver was thinking, this is not a real bug -
[...]
if that is the case, we should post a news alert about it - but i think there is a better way to handle it - it doesnt seem right, to have the package own that symlink

Hi bill. 0.0? I didn't do anything to =runlevels=. I mess up with a lot of files in my system, and there is a slight possibility that I had done it, but i certainly do not recall anything of the sort. Frankly, it sounds very unlikely. I cannot go back so long ago into my commands' history, but i really don't think that i would have created a symlink in =/etc/runlevels/default=. At the most, i would have modified /etc/init.d/dbus (that's how i found the differences).

I hope that helps (?).

#10

Updated by bill-auger over 3 years ago

On Sun, 02 Aug 2020 21:10:37 +0000 nona wrote:

i really don't think that i would have created a symlink

youre right - when i wrote that, i had not looked at the bug report too
deeply yet - the symlinks gets created by rc-update when the service is
enabled normally - thats probably what you did; and was the correct
thing to do - i think it is the new package that is doing the wrong
thing by trying to own that symlink

#11

Updated by Megver83 over 3 years ago

nona, I deleted your latest post by mistake, but read it (wanted to erase a draft). The thing is that some kind of things are not really suitable for reporting an issue, like some other more complex issues that may affect a wider amount of users. It's understandable anyways, not everyone is tech-savvy, but that's why there are other places like the forum and mailing list to ask for help before considering it a bug and report it here. Plus, you didn't mention before that you messed up with your file system. That's a problem, once it happened in my Banana Pi and pacman didn't know which files belonged to which package, and lead into a similar problem like this, but much worse.

Now, back to the issue, let's be scientific. Are you able to reproduce this conflict somewhere else, in the same way you got it before?

#12

Updated by nona over 3 years ago

Megver83 wrote:

nona, I deleted your latest post by mistake,

Oh! that cannot be undone. I will try to reproduce

> > I don't even know how did you got that file to conflict dbus.
> I didn't. The system told me there was an error, which I reported.
> > If rc-update del doesn't work, then pacman -S --overwrite will just solve your problem. Easy. OpenRC just creates symlinks inside /etc/runlevels, and dbus package comes with its symlink already so that users don't have to manually enable it as it is a core service.
> Indeed, I was able to work around this several months ago by passing the =--overwrite= option to =pacman=. By now, I don't think that it matters anymore. I got my system to work, and I was just reporting something which was not working. It seems that you are less interested in this than I am, which is totally fine.

but read it (wanted to erase a draft).

Everyone makes mistakes, don't worry.

The thing is that some kind of things are not really suitable for reporting an issue,

Oh! you should ask bill how concerned I am about that (wink, wink at bill :P )

like some other more complex issues that may affect a wider amount of users.

My issues seem to only affect me most of the time.

It's understandable anyways, not everyone is tech-savvy,

and even when they are, the idea is to report back to improve the software

but that's why there are other places like the forum and mailing list to ask for help before considering it a bug and report it here.

Are you again suggesting that I should not have reported this? that this was not a bug?

Plus, you didn't mention before that you messed up with your file system.

When I mean mess up, I mean that I create my own packages, add and modify configuration files, which seems to be the spirit of Parabola GNU/Linux. Also, I already said that I did not mess up (played around, modified, touched) the /dbus/ files, and certainly nothing with =runlevels=.

That's a problem, once it happened in my Banana Pi and pacman didn't know which files belonged to which package, and lead into a similar problem like this, but much worse.

I'm sure that you were able to solve it. That is why I keep a control of which files I modify. I would recommend you the same.

Now, back to the issue,

let's be scientific.

I certainly do not know what you mean by this, but I am going to assume that you are trying to get a real solution.

Are you able to reproduce this conflict somewhere else, in the same way you got it before?

As I said in my (deleted) post: I don't think that this matters anymore. Now, if you check the title of the bug report, it reads: /1.12.16-3.nonsystemd1/. I am now currently on version =1.12.16-5.nonsystemd1=. I imagine that to reproduce the bug, I would have to go back to =1.12.16-2.nonsystemd2= and then try to install =1.12.16-3.nonsystemd1=. I guess that you can picture how cumbersome that would be (in a rolling distro). May be, for your peace of mind (if you are looking for confirmation), you can look back at the previous reply by bill: https://labs.parabola.nu/issues/2618#note-2.

Still, I am wondering why this is marked as /not-a-bug/.

Cheers!

Also available in: Atom PDF