On Mon, Jun 20, 2022 at 3:48 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote: > > We'd like to introduce Build Number/Tag/Id in the rpm metadata. > > I agree with Vitaly: %rpmautospec+%rpmautorelease seem to cover > most of this functionality in a reasonable way. Maybe there are other > motivations / use-cases that weren't discussed that couldn't be solved > by our existing tools, but so far I don't see that. > > There were two/three reasons listed: > > > By this change we would like to: > > * Provide a possibility to change build environment and rebuild rpm > > packages without changing their content: neither sources nor spec > > files. > > Strictly speaking, rpmautospec covers this already. > It does not, because the necessary features to support build counters were deleted from rpmautospec. That said, this feature should not require adoption of rpmautospec, and there's no technical reason for that. Coupling this to rpmautospec is unnecessary and IMO unwanted. > On Mon, Jun 20, 2022 at 01:45:39PM +0200, Vitaly Zaitsev via devel wrote: > > On 20/06/2022 10:47, Petr Pisar wrote: > > > I think Aleksandra wants to (non-scratch) build all pull requestes before > > > merging. > > > > Official non-scratch builds for non-merged pull requests? Looks very > > dangerous. > > Yeah. I think we should think about scratch and non-scratch builds > separately. For scratch builds, e.g. in a pull request, it's just fine > to do repeated builds with the same NEVR. For non-scratch builds, the > fact that you cannot do that is a feature. > A merge should trigger a non-scratch build in a side-tag that can automerge once Koschei rebuilds are completed in the side tag. > > * Set a common standard for the RPM-based ecosystem, which can be used > > not just within Fedora, but also by Remixes, downstreams, SIGs and > > other distributions. > > So far downstreams and other distros used a different dist tag. I think > this is reasonable. And if they're doing other modifications apart > from a rebuild, an %autochangelog entry generated from a dist-git commit > seems better than a yet-another mechanism to provide information about > the rebuild. In particular, a build-counter doesn't see to be good fit > for this, since we'd want to distinguish different vendors that do > the build, and with a counter we can't do that and in fact risk confusion > if multiple downstreams do builds with the same number. > We have a better way to do it at the DNF level: using sticky vendors. It's not turned on yet, but it is something I'd like to do eventually. It uses the Vendor tag to differentiate sources. Fedora, COPR, OBS, RPM Fusion, CentOS, CentOS SIGs, and Red Hat all use different vendors now, so this will be possible. I'm already trying this feature out in CentOS Hyperscale with decent success. > > The most visible impact of the proposal would be the filename change: > > > > Current: dnf-4.9.0-12.fc36.noarch.rpm > > Proposed: dnf-4.9.0-12.fc36.34897715.noarch.rpm > > The history of development of rpm and the ecosystem has shown that > modifications that are visibile at the level of the output binary rpm > have a long implementation tail for the ecosystem. In particular, if > we allow add the build-number information, many many consumers will > need to adjust for this, from trivial things like regexps to match > '%dist.rpm' in the filename to complicated things that extract and > make use of the version field. So if we want to add a new feature > here, a much strong justification why what we have already is not > enough would need to be provided. > This is already something people have to expect, since our existing policy permits a tailing number and it is used for various purposes. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
