On Tue, Jan 3, 2023 at 5:11 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar(a)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>
Thank you!
josh
>
> 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:Ma...
>
>
> --
> 真実はいつも一つ!/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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