Hey pingou!
On Tue, 25 Feb 2020 at 10:26, Pierre-Yves Chibon <pin...@pingoured.fr> wrote:
>
> On Tue, Feb 25, 2020 at 12:18:24AM +0100, clime wrote:
> > Hello!
> >
> > What is the point of including number of builds into release? I think
> > the Miro's approach solves it.
> > Or is there any other problem except soname bumps?
>
> It makes it easier to do rebuilds which means it makes it easier and simpler
> to
> do mass-rebuilds.
>
> > Ad. document - annotated git tags:
> > (-) Editing the changelog would mean allowing to remove the git tags,
> > thus leading to potential issue in build reproducibility
> >
> > That doesn't need to be the case. In rpkg-util, this was resolved by
> > introducing arguments since_tag and until_tag
> > for git_changelog macro
> > (https://docs.pagure.org/rpkg-util/macro_reference.html#git-macros).
> > That's
> > how it can be prevented for some annotated tag to contribute to changelog.
> >
> > Example:
> >
> > {{{ git_changelog since_tag=name-1.3-1 }}}
> >
> > * Mon Feb 24 2020 clime <cl...@fedoraproject.org> 1.2-1
> > - manual changelog entry that is used instead of a tag annotation
> >
> > {{{ git_changelog until_tag=name-1.1-1 }}}
>
> Interesting idea.
>
> > Removing already pushed git tags is probably not a good idea anyway:
> > https://git-scm.com/docs/git-tag#_on_re_tagging
>
> We very much agree that removing git tags is not a good idea, that's why we
> listed it as a con :)
>
> > Ad. the following approach for calculating release:
> > - Compute the release field from the number of commits since the last
> > version change: <version>-<commits_number>%{dist}
> >
> > I think it is a good idea. In rpkg-util, it is done similarly, except
> > the release part has more subparts than just
> > two (including %{dist}).
>
> If you make the build system provide the ${dirty_appendix} and drop the
> ${pivot}
> (because we want to generate the release, so there is no input specified), you
> get very close to what we described.
${dirty_appendix} is a part intended for development purposes, i.e. to be able
to have versioned working tree when working locally without committing. It
will be empty if working tree is clean, which should always be the
case in a build system
(there is more info here
https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_9
on this).
I am guessing you think about number-of-builds as the
${dirty_appendix} ? That would
need to be a normal rpm macro provided by a build system (similarly to
%dist). Anyway,
if the number-of-builds part is just to optimize mass rebuild process,
I would try to look
if we can tweak the build system to be able to do the mass rebuilds
without making
new commits back to dist-git and even without that %number-of-builds macro. In
my opinion, it should be possible. There is already BUILDTIME in rpm headers
that can be used to differentiate between newer and older rpm with otherwise the
same nevr.
In rpkg-util, ${pivot} (the main release number) is generated
automatically (when the git_release
macro is employed) but packager can also hard-set it at any time to
any value. I think with
the pivot number, the upgrade-path problem would be solved cause the
commit-count appendix
is only used as delta since the last pivot change, which is marked by
an annotated tag in the git
tree. So the commit (having an annotated tag on it) in older and newer
Fedora release (branch)
would generate an rpm with the same NVR and just the %dist decides
then (there can
also be two separate tags if %dist is used in the Release string and
if it is configured
not to be empty as i do it now rpkg-util :) but this is another discussion).
The pivot is also useful for post/pre-releases and other cases described here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning
It is then useful to have something that can be configured by hand.
>
> > The full description is here:
> > https://pagure.io/rpkg-util/blob/master/f/man/rpkg_man_page.py#_262
> > but the main difference is that it counts commits from the latest
> > annotated tag which contains (in its name)
> > the current version and the current release number which are extracted
> > from the spec file when
> > creating the tag unless they are specified manually on command line.
> > Commit count is only appended
> > to it if we build from commit which is on top of some annotated tag
> > (i.e. it is itself untagged).
> >
> > Going by just a textual version change in a spec file might be slightly
> > tricky.
> > You would need to go through all the past commits that touched that spec
> > file,
> > keep checking these out and look if the version is changed when compared to
> > the
> > one parsed from the head commit. Possible though.
>
> This is basically what I had in mind.
Yes, it takes slightly more computational time than being navigated by tags
themselves that can be used for version bumps as well as release bumps.
>
> > To go back to your original post:
> > > For both the release and the changelog fields we believe using RPM macros
> > > would
> > > satisfy the requirements we have for opting-in/out:
> >
> > By using such RPM macros, you would lose ability to rebuild srpms
> > because it will
> > be only possible to build them when the git context is present but not when
> > they
> > become a standalone thing. I.e. things like this will not work:
> >
> > https://github.com/rpm-software-management/mock/blob/cfe34c8a57/mock/py/mockbuild/backend.py#L270
> >
> > That's why I think that such macros should be of a different kind:
> > macros that are computed
> > once when srpm is created and result of which is put _verbatim_ into
> > the spec file so that
> > there is no (re)computation later when srpm is being built and when
> > the git context is already
> > missing.
>
> We had a discussion with Neal about this topic on #fedora-apps yesterday and I
> believe one of the outcome of this discussion was that we should indeed use
> this
> approach, for the reasons you're mentioning.
>
>
> Thanks for your feedbacks and thoughts (and links!)
Right, I will be very happy if I can collaborate on this.
clime
>
> Pierre
> _______________________________________________
> 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
_______________________________________________
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
