-
Notifications
You must be signed in to change notification settings - Fork 37
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
Comments
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: I'm hesitant to carry distribution-specific instructions in the upstream development repository for two reasons:
That being said, I do have a work-in-progress branch to add a There is one annoying quirk that I haven't fixed yet. When I build the src.rpm locally, I cannot see why the src.rpm does not get configured with a populated |
My experience with other projects is that
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 |
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.
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.
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.
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 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. |
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 When project becomes big and complex (and Correct me if I'm wrong, but I assume that making changes to
Or do you use some trick with |
I spent a little time fiddling around with COPR some more and discovered a workaround to force populating the empty # 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
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.
There's nothing tricky happening downstream to package it. Just the standard |
I think we found a solution to this through 25647b0 |
The git repository of upstream (on GitHub) does not contain
yggdrasil.spec
file. Because of that:tito
/mock
/packit
/rpmbuild
and install it to the systemThe text was updated successfully, but these errors were encountered: