Fallback to using system wlroots development files

[JamiKettunen]

To make packaging this for distros a whole lot nicer (or mergeable in the first place) there should be a fallback to locating system wlroots instead of forcefully trying to use the Bundled wlroots under subprojects/wlroots.

I know this currently Closely follows wlroots-git but are there plans to later make releases that build against latest tagged release of wlroots?

[vaxerski]

to later make releases that build against latest tagged release of wlroots

most likely not.

To make packaging this for distros a whole lot nicer (or mergeable in the first place) there should be a fallback to locating system wlroots instead of forcefully trying to use the Bundled wlroots under subprojects/wlroots.

not possible.

[JamiKettunen]

most likely not.

why not? I get that the current main branch should build and work with close-to-latest wlroots-git commits, I have absolutely no issue with that, but you'd not consider making releases later build against tagged wlroots versions?

not possible.

because? I don't see why it wouldn't be; if the releases against stable wlroots happen I don't see why something similar to sway's old FindWlroots.cmake wouldn't work

[vaxerski]

wlroots head has many breaking changes compared to latest tagged release. If I wanted to keep releases that have a tagged wlroots ver, I could either:

• release every time wlroots makes a tag (like what 2-6 months?)
• keep two hyprland versions supported

as you can see it'd be a pain in the ass.

The most reasonable version if I was forced at gunpoint to support tagged wlroots releases would be to make a script (or pragmas, ugh) that control code based on the wlroots ver. Even then, some features might break on wlroots 0.16-dev, and not 0.15, and vice versa. Pure pain.

[vaxerski]

Still, I don't understand your problem. Hyprland builds wlroots and uses a separate .so, making it independent of the system wlroots. If you want a static link, you can use the meson build with a static flag (see the original PR) Where does it "interfere" with anything?

[JamiKettunen]

I just don't think it's normal for release versions of software to require an arbitrary git hash of a dependency that hasn't yet had a tag either; there wouldn't need to be any shenanigans regarding supporting two versions of wlroots at the same time if all development was focused around the latest wlroots tagged release instead.

Am I missing something or is there some reason this project has to follow wlroots-git closely? The "many breaking changes" can be addressed when a new release of wlroots comes out, this is already what basically every other piece of software I know does with their own dependencies.

I'm not saying you should downgrade back to wlroots 0.15 now, but this could be something to address in the future once 0.16 is released for example.

[viperML]

@JamiKettunen what is the problem with bundling a dependency that doesn't occupy the package of wlroots? Would copying the entire wlroots tree into this repo make any difference?

[vaxerski]

I just don't think it's normal for release versions of software to require an arbitrary git hash of a dependency that hasn't yet had a tag either;

??????? have you ever seen software

Am I missing something or is there some reason this project has to follow wlroots-git closely? The "many breaking changes" can be addressed when a new release of wlroots comes out, this is already what basically every other piece of software I know does with their own dependencies.

Wayland and wlroots are quickly going forward in development. Very quickly. We want to allow users to use the absolute latest wayland features.

what is the problem with bundling a dependency that doesn't occupy the package of wlroots? Would copying the entire wlroots tree into this repo make any difference?

exactly my point.

[eli-schwartz]

Wayland and wlroots are quickly going forward in development. Very quickly. We want to allow users to use the absolute latest wayland features.

Most (not all) Linux distributions disagree with this philosophy and, as a general rule of thumb, have policies that forbid one package (such as Hyprland) to arbitrarily rely on the absolute latest git development features of a dependency (such as wlroots).

They will stick to this philosophy regardless of the build system you use, regardless of whether you "copying the entire wlroots tree into this repo", regardless of whether you build wlroots as a static link, and regardless of whether you use a separately named .so; what they actually want is to stick to their policy that software should commit to supporting a stable version of the dependency and then use the existing system version.

Unfortunately that means that if projects don't agree to be compatible with what the distro wants, the distro will simply tell users "Hyprland $DISTRO will NEVER use system wlroots package Hyprland", which means that users will need to figure out everything for themselves.

...

Typically this then means users need to compile it themselves using e.g. the Arch Linux AUR or manually git cloning.

In some cases, there may be a Fedora COPR, Ubuntu PPA (Personal Package Archive), or some other distro-specific mechanism for third-party packages that aren't required to closely follow Linux distro policies.

[ErikReider]

Wouldn't specifying a compatible wlroots commit be a better approach? So when cloning the submodule, that specific compatible commit is used and compiled instead of the latest (I'm not familiar with git submodules so forgive me if this isn't possible)

[EinderJam]

...

Typically this then means users need to compile it themselves using e.g. the Arch Linux AUR or manually git cloning.

May I add, even current AUR's pkgbuild conflicts with already installed wlroots and wlroots-git

[eli-schwartz]

Wouldn't specifying a compatible wlroots commit be a better approach?

No, because that completely ignores the reality of the matter, which is that this is about opposing ideology, and also about which side backs down first. (By the way, distros are fairly practiced at not backing down, they have tens of thousands of packages, and are pretty likely to say "just use one of the other 50 WMs we package".)

There is nothing you can say that will make them say "oh yeah, you're right, this is a compatible approach".

They will either refuse to package Hyprland because "it violates our policy", or they will say "this violates our policy but we've decided that the policy no longer matters, because this one (1) package called Hyprland is more important than our policy".

May I add, even current AUR's pkgbuild conflicts with already installed wlroots and wlroots-git

I... mentioned this even? The AUR is unofficial user-supplied stuff, which is marked "use at your own risk", and doesn't have a mandatory QA process, doesn't actively vet packages for malware (users are expected to check this themselves; malware is rare but does happen), and certainly doesn't enforce any kind of policy.

Many Arch users find compiling software themselves to not be to their taste anyway, and refuse to use the AUR. Many don't know how to use the AUR, and don't care to learn. And also, many users don't use Arch Linux... this ticket was opened by a Void Linux user.

[vaxerski]

May I add, even current AUR's pkgbuild conflicts with already installed wlroots and wlroots-git

it does not. It used to like 3 months ago. (Unless Kainoa fucked up the pkgbuild again in which case I'll have him prosecuted for violating the geneva convention)

Most (not all) Linux distributions disagree with this philosophy and, as a general rule of thumb, have policies that forbid one package (such as Hyprland) to arbitrarily rely on the absolute latest git development features of a dependency (such as wlroots).

ok and? If $DISTRO does not want to package Hyprland, I will not force them. Their decision. I have a requirement. If a distro is unwilling to fulfill it, cool.

And if you share the distro's mindset of "Nyeh I won't allow newest stuff because no" then you just don't want to use Hyprland. That's really it.

There are releases that are pre-compiled for a reason. They provide a special .so that will not conflict with any other .so. You also have the meson option, which probably in the future I'll add to the releases as well for people who need a static link. If you or $DISTRO have a problem with that, they can like, not package Hyprland, I won't cry about it, and I never have been.

[eli-schwartz]

I am merely pointing out that the distro mindset exists. I'm not trying to convince you to cry about it. :)

Not being interested in having your software packaged in a distro, and simply recommending users to download the precompiled releases, is a perfectly valid choice to make.

Not all users are brave enough to use software that isn't provided by their package manager, but they aren't forced to use Hyprland. 🤷

[vaxerski]

If you are trying to convince me to tag because "they aren't forced to use Hyprland", then it won't work. We have a mindset. If someone refuses to work with it, we won't get along. As you can clearly see, Arch and Nix work with our mindset. If Void / whatever don't, their problem.

tl;dr:
No.

[EinderJam]

May I add, even current AUR's pkgbuild conflicts with already installed wlroots and wlroots-git

it does not. It used to like 3 months ago. (Unless Kainoa fucked up the pkgbuild again in which case I'll have him prosecuted for violating the geneva convention)

Hi, sorry for replying so late, but the pkgbuild indeed conflicts with wlroots and wlroots-git since last update (but don't hurt @ThatOneCalculator please ^^)