[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
From:       Neal Gompa <ngompa13 () gmail ! com>
Date:       2023-01-03 22:10:37
Message-ID: CAEg-Je8r4SPCQFSQ4OtaAyYnJV7qbRmbx3rErXEnPzoysa2eBQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer <jwboyer@fedoraproject.org> wrote:
> 
> On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar@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.

[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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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


[prev in list] [next in list] [prev in thread] [next in thread]