Closed xyproto closed 1 year ago
@elcuco What do you mean?
Getting patches and bug reports also from Arch Linux users could be very valuable.
The Arch package was last updated almost 2 months ago. That's basically an eternity for a project that's being developed at such a fast pace. Users that download the package will have a significantly worse experience than those who build from source. We'd also get confused people asking why things shown in Andreas' later videos don't work for them.
I'm not opposed to others providing binary distributions of Ladybird; however, that requires continuous effort to maintain and keep up to date. If that does not happen, the package has no place being featured in the documentation.
~ just my two cents. This is not an official position of the project.
This is not an official position of the project.
Agree with everything you said, I'll make it official. :)
@linusg
I am the maintainer of the ladybird package. Without git tags with new versions, deciding when to make a new release will always be an arbitrary decision by the package maintainer.
Adding installation instructions to the README is a different matter.
Please re-consider this PR.
The latest commit of Ladybird builds, but does not appear to run on Arch Linux (PKGBUILD).
@BertalanD @linusg When there is no git release tag that can be used, what does the Ladybird developers envision that should trigger new package releases, if the latest git commit is not a viable option?
deciding when to make a new release will always be an arbitrary decision by the package maintainer.
Precisely, at this point in time (and likely for the foreseeable future), a Ladybird "release" is exactly that - an arbitrarily chosen git commit, which we're not going to choose for you. The only version we care about is HEAD
.
@linusg HEAD currently does not currently build on Arch Linux, though, which does not go hand in hand with the expectations that the Arch Linux package should not rely on the latest git tag, but only on the latest commit.
Do you have logs for the build failure? The last time I checked, I had no problems building Ladybird on Arch.
Have you tried building without the PKGBUILD machinery, following our instructions? Does that also fail?
Without logs, I only have a wild guess: you should pin the commit SHA of both the Serenity and Ladybird repos. I think our CMake setup always tries to fetch the latest Serenity commit, which might have since received commits that are incompatible with the old Ladybird revision. You will likely need to clone the specific Serenity commit separately, and tell CMake to use it with -DSERENITY_SOURCE_DIR
.
I suspect the issue is related to the requirement to use gcc >= 12, or clang >= 13. I agree that a build log would be helpful, I couldn't find anything about a public build pipeline or CI infrastructure like Fedora has.
The pkgbuild also doesn't take advantage of our install
rules, and as such doesn't copy over the WebContent binary to the bin/ directory. How do we submit patches to the pkgbuild? It looks like the canonical configuration management for it is the svn repositories?
IMO there is no reason to have installation instructions for a "product" we don't release. If others are interesting in maintaining packages on their own, that's wonderful, but we purposefully change Ladybird and Serenity way too frequently for that to be something we need to support in our own README. We overwhelmingly prefer people building from source, the codebases are far too volatile to support anything else.
If a build breaks on a specific distro, the SerenityOS Discord is the place to ask about that (with build logs). Or even better, opening a PR that address those platform-specific issues.
@BertalanD The issue with using the latest commit instead of a git tag is not mainly about building Ladybird, but how it behaves when executing the binary after building (ref #116). Thanks for the tips, though!
@ADKaster If CMake could be used to package the files, that would be excellent. Requests for changes to PKGBUILD files are welcome at https://bugs.archlinux.org/. Alternatively, commenting on the page for the unofficial Ladybird package could be a low-threshold way.
@trflynn89 That is understandable. But as long as Ladybird is published as an open source and stand-alone browser, I wish to do whatever I can to give the project a friendly nudge, even if it's just packaging it as an official Arch Linux package. Anything to try to counter-act a future browser engine monopoly. Git tags (and to a certain degree installation instructions for users of Linux distros or other operating systems) are helpful when packaging software, that's all.
This can be closed - as it has no real value to the project.