search

regolith-linux / sway-regolith

i3-compatible Wayland compositor
https://swaywm.org
MIT License
6 stars 2 forks source link

fix: use Provides for sway instead of Conflicts #21

Closed SoumyaRanjanPatnaik closed 1 month ago

SoumyaRanjanPatnaik commented 1 month ago

This is required to ensure the packages that depend on sway to remain installable due to sway-regolith providing it as a virtual package. A good example of such a package is grimshot which is screenshot app created by the sway creators.

kgilmer commented 1 month ago

One question @SoumyaRanjanPatnaik , is there anything that prevents 100% back-compat of sway-regolith to sway? (if a user had sway installed and then it's replaced with sway-regolith, would any regressions be expected if they run a "stock" sway desktop session?)

kgilmer commented 1 month ago

Also, this change seems to produce a build regression: https://github.com/regolith-linux/voulage/actions/runs/9114401213/job/25058609909#step:3:5273

Perhaps we also need to declare a Replaces on sway?

SoumyaRanjanPatnaik commented 1 month ago

One question @SoumyaRanjanPatnaik , is there anything that prevents 100% back-compat of sway-regolith to sway? (if a user had sway installed and then it's replaced with sway-regolith, would any regressions be expected if they run a "stock" sway desktop session?)

sway-regolith IS, in fact, 100% backwards compatible with sway. However, the config model of regolith isn't compatible with sway, since it heavily utilizes the set_from_resource command, which sway doesn't support (and, AFAIK, they never plan to).

Currently, neither package can be installed on the same machine. This is because the sway also installs many utilities(swaybar, swaynag, etc) as part of the same binary package. Considering this, we only have two options (that I can think of):

  1. Don't package the sway utils as part of the sway-regolith binary package and use these from the official sway binary package
  2. Keep sway and sway-regolith packages mutually exclusive. As you suggested in your second comment, Provides + Replaces might do the trick. We might also need to keep Conflicts (see this section from the docs).
SoumyaRanjanPatnaik commented 1 month ago

Don't package the sway utils as part of the sway-regolith binary package and use these from the official sway binary package

Note that this has the implication of always having both sway and sway-regolith installed at the same time, which I assume is less than ideal.

Keep sway and sway-regolith packages mutually exclusive. As you suggested in your second comment, Provides + Replaces might do the trick. We might also need to keep Conflicts (see this section from the docs).

Going with this approach has some merit IMO. In this case, fi would prefer the executable for sway-regolith to be renamed to sway, since that would allow for maximum compact with the sway package.

kgilmer commented 1 month ago

IMO the ideal case for users is that both packages can live together on the same host. This lets someone try Regolith (or Sway) without major changes. If we opt to just ship the sway-regolith binary in our package, I expect that we are cleanly isolated between the stock config file and the Regolith variant (which includes the set_from_resource decls, etc.. ) due to the fact that the stock sway session would be looking in /etc/sway/ (or whatever) and our Regolith session would specify path to our config files. Am I missing something?

SoumyaRanjanPatnaik commented 1 month ago

IMO the ideal case for users is that both packages can live together on the same host. This lets someone try Regolith (or Sway) without major changes. If we opt to just ship the sway-regolith binary in our package, I expect that we are cleanly isolated between the stock config file and the Regolith variant (which includes the set_from_resource decls, etc.. ) due to the fact that the stock sway session would be looking in /etc/sway/ (or whatever) and our Regolith session would specify path to our config files. Am I missing something?

The problem with allowing both packages to live together is conflicting binaries that ship with them, for example swaymsg, swaynag, swaybar etc. They are packaged by both regolith and sway.

If we just ship the sway-regolith binary in our package, we would need to have a way to bring in these utilities as well. Unless we figure out an alternative, this would probably mean our session would have a dependency on both sway-regolith and the official swaypackage.

Maybe we can try something like Depends: sway-utils-regolith | sway in the dependencies for sway-regolith and have sway-utils-regolth conflict with sway. The sway-utils-regolith package in this case would have all the utilities that currently conflict with the sway-regolith binary package.

SoumyaRanjanPatnaik commented 1 month ago

BTW, building this package locally, as it stand now, seems to work. I'm also able to install it. The CI logs didn't make the reason for failure clear enough.

kgilmer commented 1 month ago

The CI logs didn't make the reason for failure clear enough.

True, but I believe this problem existed a few months back as well. I don't this is a transient or build-system issue. I'm guessing the package resolver fails in an uncommon place.

After looking at the source and build a bit, I notice there are really only three shipping files that are required and collide with upstream:

Of these additional binaries, I believe there is no ABI concern with upstream (eg sway-regolith 1.9 build calling swaymsg 1.9 from upstream) and so it would be possible to somehow "share" these dependencies across packages.

I notice the space cost of these binaries:

-rwxr-xr-x 1 root root 144K Apr 19 07:57 /usr/bin/swaybar
-rwxr-xr-x 1 root root  31K Apr 19 07:57 /usr/bin/swaymsg
-rwxr-xr-x 1 root root  72K Apr 19 07:57 /usr/bin/swaynag

IMO this does not impose an unreasonable space overhead if users end up with both upstream and regolith versions of these files.

Two options come to mind that allow both upstream and regolith packages to coexist:

  1. In the regolith package, create another binary package for these programs (sway-regolith-extras?). Have that package conflict with sway. Specify that sway-regolith depend on sway OR sway-regolith-extras. This is the "optimized" path that prevents any duplication and keeps the names consistent with upstream.

  2. In the build system (and in source where the names are referenced) rename the colliding files with a -regolith suffix. (eg /usr/bin/swaymsg-regolith). Users may have both packages installed. They would have duplicates of the colliding files. This solution is simpler from a dependency model perspective, but has the space cost.

I don't think either solution is complex or difficult. You're more familiar though w/ the sway codebase, dependencies, etc.. Did I miss any dragons or other concerns @SoumyaRanjanPatnaik ?

kgilmer commented 1 month ago

I've created this PR ^ to test out option 1

kgilmer commented 1 month ago

I played around with option 2 above, but it quickly got pretty messy. swaymsg does a lot of lifting, and creating a separate swaymsg-regolith ends up causing a lot of noise in docs and code. Not as clean as I'd hoped for. Given that, and that I am unable to get consistent package resolver behavior w/ other changes, added two meta packages for direct control of these dependencies and another experiment to see how we might yet influence the solver.

kgilmer commented 1 month ago

I cannot find a packaging solution that produces the desired behavior:

  1. Installs our package in the case that upstream is not installed
  2. Does not replace upstream package if it has been already installed

Additionally, the option of renaming the binaries is unsatisfactory due to the resulting noise IMO. They would "pollute" config files such that sway and sway-regolith config stanzas would not be sharable. While this is already true to some degree given the Xresource integration we have, the problem would be worse due to swaymsg I think.

The "best" option that comes to mind now (assuming a packaging solution cannot be found) would be a hard fork of sway IMO.

edit: short term for the 3.2 release I think it's best to just declare a Conflicts from sway-regolith against sway.

SoumyaRanjanPatnaik commented 1 month ago

Additionally, the option of renaming the binaries is unsatisfactory due to the resulting noise IMO. They would "pollute" config files such that sway and sway-regolith config stanzas would not be sharable.

100% agree with this.

Short term for the 3.2 release I think it's best to just declare a Conflicts from sway-regolith against sway.

Hmm... I still think we should also Provides sway, even if we don't replace it.

SoumyaRanjanPatnaik commented 1 month ago

How about having the sway-regolith package Provides: sway, Conflicts: sway and Replaces: sway, and renaming the sway-regolith binary we currently use back to just sway?

In my mind, this should allow the user should still have a functionally equivalent version of sway, plus the trawl / Xresources integration and context menu support for swaybar, making the sway-regolith a drop-in for sway.

kgilmer commented 1 month ago

https://github.com/regolith-linux/sway-regolith/pull/28