Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing yggdrasil.spec file #121

Closed
jirihnidek opened this issue May 9, 2023 · 6 comments
Closed

Missing yggdrasil.spec file #121

jirihnidek opened this issue May 9, 2023 · 6 comments

Comments

@jirihnidek
Copy link
Contributor

jirihnidek commented May 9, 2023

The git repository of upstream (on GitHub) does not contain yggdrasil.spec file. Because of that:

  1. It is not possible to create testing rpm using tito/mock/packit/rpmbuild and install it to the system
  2. It is not possible to do testing of building rpm as part of CI testing
@subpop
Copy link
Collaborator

subpop commented May 10, 2023

It had one, but I removed it when I ported the build system to meson. I have not added such a thing back yet because I don't consider the absence of a spec file to be that important. The software can be built and installed from the source directory by running: meson setup -Dprefix=/usr builddir && meson compile -C builddir && sudo meson install -C builddir.

I'm hesitant to carry distribution-specific instructions in the upstream development repository for two reasons:

  1. It implies an unnecessary distribution-bias. The software should run on any distribution; if it does not, I consider that a bug. Carrying one distribution's build instructions and not another implies one distribution is more supported than another.
  2. The instructions to build an RPM inevitably deviate from the downstream instructions, creating two problems: (1) changes to one file must be analyzed to determine whether they should be applied to one or the other, or both; (2) the built artifact is not the same as the one built by downstream distributions because of the differences aforementioned.

That being said, I do have a work-in-progress branch to add a .copr directory back and support compilation into an RPM using COPR: https://github.com/RedHatInsights/yggdrasil/tree/add-copr

There is one annoying quirk that I haven't fixed yet. When I build the src.rpm locally, %dist gets set correctly with the contents of %distprefix as generated by %forgemeta. But when COPR performs the SRPM build, it defines %distprefix correctly, but then %dist is empty. I can't see anything in the logs that indicate why. When the x86_64.rpm is built, it does get a value set correctly in %dist. I feel like this is a problem with the COPR build host when building the src.rpm.

I cannot see why the src.rpm does not get configured with a populated %dist value, while the binary build does. It's not a hug blocker, but it does make browsing the list of builds difficult to identify which build is which.

@jirihnidek
Copy link
Contributor Author

jirihnidek commented May 10, 2023

My experience with other projects is that yggdrasil.spec file is IMHO something MUST HAVE. Why?

  1. At the end you have to create and modify the .spec file anyway.
  2. It is easier to maintain .spec file during upstream development.
  3. It is so easy to create scratch build and do pre-verification.
  4. It is easy to uninstall installed rpm. There is nothing like meson uninstall.
  5. Testing of new complex functionality during PR review is really easy, when you can build rpm locally. You can test not only installing of rpm, but also uninstalling and upgrading.

Yeah, there will be possibility of some downstream differences, but probability of that is really low, and in the most cases you can use upstream .spec for building downstream too.

@subpop
Copy link
Collaborator

subpop commented May 10, 2023

At the end you have to create and modify the .spec file anyway.

Not if you're maintaining the package in Debian or Arch Linux. My point is that assuming a spec file is the default way to install software is narrowing the focus of the software unnecessarily. Fedora's build instructions are not the same as openSUSE, but both use RPM and spec files, so if we ship a file called "yggdrasil.spec", whose standards should we follow? Distribution-specific build instructions should remain in the distribution's repositories.

It is easier to maintain .spec file during upstream development.

I agree that upstream development may result in changes to the downstream spec file (new files get added, build steps change, etc.), and knowing about those changes as soon as possible is valuable. But I don't think the cost of changing the spec file in dist-git downstream is a huge burden either.

It is so easy to create scratch build and do pre-verification.

If your targeted distribution expects the notion of scratch builds and pre-verification, then yes, having build instructions upstream can make that downstream work easier.

It is easy to uninstall installed rpm. There is nothing like meson uninstall.

True, if you're installing files onto your host machine, that's a risk you have to consider. I always develop in a VM, so I often run virsh snapshot-revert --snapshotname "Just installed" my-dev-vm to refresh things. I don't usually install yggdrasil on my host; I do run it, but I run it directly out of the source directory.

Please don't take this as me being obstructive; I do want to find a way to enable continuous builds of yggdrasil for downstream consumers to easily consume built artifacts, but I don't feel like carrying an RPM spec file in the upstream repository is the ideal solution.

@jirihnidek
Copy link
Contributor Author

No, I really do not want to use VM snapshots to revert changes in few bits. I have this experience from one project and it is something horrible. No, never again.

Red Hat is main sponsor of yggdrasil development, right? Most of developers and contributors uses Fedora or RHEL based systems, right? Thus, I believe that we deserve to have one small configuration file with suffix .spec in upstream repository. I don't believe it is too much. Other distributions (if any) can for example maintain their own spec files (or patches of upstream .spec file) in their own distribution repositories.

When project becomes big and complex (and yggdrasil has this potential), then ability to build rpm locally from .spec file is important to be able to do relatively effective development and testing of changes in .spec file.

Correct me if I'm wrong, but I assume that making changes to .spec file in downstream is something like this: You have to:

  1. Commit changes
  2. Create some temporary tag
  3. Push temporary tag
  4. Some rpm build systems (COPR, packit, etc.) downloads yggdrasil-*tar.gz file from github and tries to create RPM and after all of this you can see result of build.

Or do you use some trick with rpmbuild?

@subpop
Copy link
Collaborator

subpop commented May 11, 2023

I spent a little time fiddling around with COPR some more and discovered a workaround to force populating the empty %dist macro... by defining it manually in the spec file. This is a good example of the kind of deviation that I dislike when keeping distribution build instructions upstream. Inadvertently migrating this kind of workaround downstream, where it is unnecessary, can lead to unforeseen issues later on as changes are made to the downstream build environment.

# Manually redefine %%dist to work around an issue in COPR where the build root
# that creates the srpm does not define a value for %%dist. This should *NOT* be
# carried in downstream; this is strictly an upstream/COPR/CI workaround.
%global dist %{distprefix}.fc%{fedora}

However, it does embed the commit hash into the NVR of both the source and binary RPMs, so it fixes my final obstacle to adding back the COPR support. I'll open a PR to merge this branch into main.

No, I really do not want to use VM snapshots to revert changes in few bits. I have this experience from one project and it is something horrible. No, never again.

I agree. I don't want this project to prefer one way of development over another. It currently doesn't encourage or require the use of any specific development software or workflow, and I'd like to keep it that way.

Correct me if I'm wrong, but I assume that making changes to .spec file in downstream is something like this: You have to:

Commit changes
Create some temporary tag
Push temporary tag
Some rpm build systems (COPR, packit, etc.) downloads yggdrasil-*tar.gz file from github and tries to create RPM and after all of this you can see result of build.

Or do you use some trick with rpmbuild?

There's nothing tricky happening downstream to package it. Just the standard fedpkg workflow.

@subpop
Copy link
Collaborator

subpop commented Jul 19, 2023

I think we found a solution to this through 25647b0

@subpop subpop closed this as completed Jul 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants