Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#78184 - [greetd] unavoidable circular dependencies?

Attached to Project: Community Packages
Opened by Lex Black (TrialnError) - Wednesday, 12 April 2023, 19:47 GMT
Last edited by Caleb Maclennan (alerque) - Saturday, 22 April 2023, 07:33 GMT
Task Type General Gripe
Category Packages
Status Closed
Assigned To Caleb Maclennan (alerque)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
First thing: Nice that more wayland related projects find their way into the repos :)

But I noticed some odd things while getting rid of my custom packages and installing the repo packages for greetd and greetd-tuigreet.
Firstly greetd-tuigreet requires greetd but is also required by greetd via the meta dep greetd-greeter. But afair greetd-tuigreet doesn't need greetd for building the package. And this wasn't a mistake by an AUR PKGBUILD, because I built those packages in a clean environment and the packages worked. Didn't check the other greeters, but I assume this is similar for those.

Secondly: agreet is split from the greetd source into a separate package. It provides greetd-greeter but is also added as an explicit dep to greetd. So greetd-agreet will be installed everytime. Even if one has changed the default config and doesn't require it anymore. If this should ensure to work with the default config it shouldn't be split. And if it should be a separate/optional option, then it should be entirely optional even if this results in a broken default.

Personally I liked the optdepends approach from the AUR version, although I see the appeal of the meta dep. On the other hand, the greeters aren't needed for compiling greetd...
Dunno what is the best solution, but I think the current approach is kinda suboptimal?
This task depends upon

Closed by  Caleb Maclennan (alerque)
Saturday, 22 April 2023, 07:33 GMT
Reason for closing:  Won't fix
Comment by Caleb Maclennan (alerque) - Saturday, 22 April 2023, 07:33 GMT
For repo packages, end users don't need to care about what is required at compile time. tuigreet does require greetd to *run*, hence the dependency.

The agreety split was/is in the hopes of making it optional someday, but that can only happen after the default configs get worked out so we don't accidentally leave people with a system they can't log into.

I've talked to some other users and upstreams and this was the best arrangement we could come up with that wouldn't cause breakage. As the upstream projects get things worked out it should be easier for the dependencies to make more sense. Also as more greeters get packaged the virtual dependency will make more sense.

Loading...