On Tue, Jan 3, 2023 at 5:10 PM Neal Gompa <ngomp...@gmail.com> wrote: > > On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer <jwbo...@fedoraproject.org> wrote: > > > > On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppi...@redhat.com> wrote: > > > > > > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a): > > > > Have we made sure that when Red Hat forks Fedora packages for RHEL > > > > that they don't truncate or eliminate the Git history anymore? Because > > > > I would > > > > personally be very displeased if my historical attribution went away > > > > because of broken processes like the one used to fork all the Fedora > > > > Linux 34 packages for CentOS Stream 9. > > > > > > > It's not only about loosing attributions. There will be NEVRA > > > discrepancies in > > > RHEL: > > > > > > Different number of commits will mean different release numbers. That will > > > break package interdependencies which requires a specific release number. > > > E.g > > > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus > > > Fedora foo > > > will strengthen the dependency with "Requires: bar >= 1-2". However, after > > > importing to RHEL, bar will become bar-1-1. The dependency from foo will > > > break. > > > > That's a good point. The design works well within a single, > > continuous development environment such as Fedora's but any usage of > > the sources outside of that, either by importing SRPMs or by importing > > subsets of dist-git, seems like it would struggle. Does something > > like OBS suffer from the same issue? Seems it would, but I don't know > > much about how OBS works. > > > > OBS parses the spec file on import and sets the Release value auto > increment based on the value of the Release field at import time. Then > when you do a version bump, it resets the Release field back to 1. > > OBS does not (by default) let you control the Release field, though a > project/instance admin can change these defaults. By default, OBS > overrides the Release value and does its own increments with a commit > counter and a build counter, formatted as such: <CI_CNT>.<B_CNT> > > If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first > build. Any triggered rebuilds will bump the build counter. When you > bump to foo-6, then the new build will be foo-6-1.1. > > If you want to tweak OBS to retain the spec file Release value, you > can configure the project or the instance entirely to use another > scheme. For example, for the OBS project that obsctl is released > to[1], the scheme is <SPEC_REL>+obs<CI_CNT>.<B_CNT>. That allows the > original spec file's Release value to remain, while allowing OBS' > generated data to be appended. You can see this in motion with a build > of obsctl[2], where you can see that we've done the 6th rebuild of the > 11th checkin of commit b6e1e99. >
I should clarify here a bit, this is the 11th checkin into the OBS SCM, not the 11th checkin of the Git commit: https://build.opensuse.org/package/revisions/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
