this appears to cause no collision on install IIRC (probably due to CONFIG_PROTECT), but if both are installed then one is uninstalled, this removed the file for me and caused lightdm to stop functioning ("not authorized to own bus name") I assign bug to hwoarang because of alphabetical order, but I do not know which package is right (if either).
There should be a collision of files even with CONFIG_PROTECT @portage is this expected behavior?
er, I wanted to say "I don't recall there being a collision message; in any case, the packages were both installed successfully." I don't remember which I installed first, but both were in and working properly, then I removed sddm and lightdm stopped working with no warning. I then re-merged lightdm and it resumed working.
(In reply to Alex Xu (Hello71) from comment #0) > this appears to cause no collision on install IIRC (probably due to > CONFIG_PROTECT) Right, it's left to the user to resolve the collision when they run etc-update, dispatch-conf, or whatever.
(In reply to Zac Medico from comment #3) > (In reply to Alex Xu (Hello71) from comment #0) > > this appears to cause no collision on install IIRC (probably due to > > CONFIG_PROTECT) > > Right, it's left to the user to resolve the collision when they run > etc-update, dispatch-conf, or whatever. hrm. it's possible that I went through it with d-c and forgot about it. the only thing I'm totally sure of is "I depcleaned sddm and lightdm stopped working".
(In reply to Alex Xu (Hello71) from comment #4) > hrm. it's possible that I went through it with d-c and forgot about it. I was talking about when installation operations, so it doesn't apply to the specific case that you have complained about. > the only thing I'm totally sure of is "I depcleaned sddm and lightdm stopped > working". If the config file is identical to the version that was initially installed by the package (no user modifications), then portage will unmerge the file despite CONFIG_PROTECT. I suppose that we could improve the behavior in this case by making portage search for other packages that own the CONFIG_PROTECTed file. However, that could introduce a significant performance penalty, depending on the number of config files being removed.
(In reply to Zac Medico from comment #5) > (In reply to Alex Xu (Hello71) from comment #4) > > hrm. it's possible that I went through it with d-c and forgot about it. > > I was talking about when installation operations, so it doesn't apply to the > specific case that you have complained about. > > > the only thing I'm totally sure of is "I depcleaned sddm and lightdm stopped > > working". > > If the config file is identical to the version that was initially installed > by the package (no user modifications), then portage will unmerge the file > despite CONFIG_PROTECT. > > I suppose that we could improve the behavior in this case by making portage > search for other packages that own the CONFIG_PROTECTed file. However, that > could introduce a significant performance penalty, depending on the number > of config files being removed. So best to block each other with soft-blockers then?
(In reply to Markos Chandras from comment #6) > (In reply to Zac Medico from comment #5) > > (In reply to Alex Xu (Hello71) from comment #4) > > > hrm. it's possible that I went through it with d-c and forgot about it. > > > > I was talking about when installation operations, so it doesn't apply to the > > specific case that you have complained about. > > > > > the only thing I'm totally sure of is "I depcleaned sddm and lightdm stopped > > > working". > > > > If the config file is identical to the version that was initially installed > > by the package (no user modifications), then portage will unmerge the file > > despite CONFIG_PROTECT. > > > > I suppose that we could improve the behavior in this case by making portage > > search for other packages that own the CONFIG_PROTECTed file. However, that > > could introduce a significant performance penalty, depending on the number > > of config files being removed. > > So best to block each other with soft-blockers then? that's definitely not a good idea. there's no reason why you shouldn't be able to have two different display managers on the same machine (say, one on local logins and one on remote, I don't know). both install mostly the same file AFAIK ("allow root to own this bus name"), which is why they both work if one installs it. I think that assuming dbus is OK with it, just make them install two different files, e.g. lightdm-org.freedesktop.DisplayManager.conf and sddm-org.freedesktop.DisplayManager.conf.
Sddm upstream commit in master branch allows to set different config name. Patch could be backported to the release version(s).
I'll try to fix it ASAP.
