Re: Ideas and proposal for removing changelog and release fields from spec file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 25 Feb 2020 at 12:47, clime <clime@xxxxxxxxxxxxxxxxx> wrote:
>
> Hey pingou!
>
> On Tue, 25 Feb 2020 at 10:26, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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 <clime@xxxxxxxxxxxxxxxxx> 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

Sry for the weird line breaks, i need to tweak my mail "client" not to do that.

>
> >
> > Pierre
> > _______________________________________________
> > 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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux