On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar@xxxxxxxxxx> 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. [1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf [2]: https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git/Fedora_Rawhide -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
