Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V4

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

 



On Tue, Apr 7, 2020 at 7:33 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote:
>
> On Mon, Apr 06, 2020 at 06:48:17PM -0400, Neal Gompa wrote:
> > On Mon, Apr 6, 2020 at 6:22 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
> > > On Mon, Apr 6, 2020 at 6:09 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> > >> I've personally been burned enough times by not having versioned
> > >> DistTags for personal rebuilds that I would strongly suggest you
> > >> reconsider having unversioned ones.
> > >
> > > Would you mind explaining some of the situations in which you were burned?
> > > I’m not ruling this out, but I’d like a clear justification if we were to
> > > change something.
> > >
> > So, prior to me building my packages in OBS and getting auto-bumping
> > Releases, I used to bump into issues all the time with building openSUSE
> > packages in an environment like Koji's, where the NVR is the key for
> > a unique package. openSUSE does *not* define a DistTag or the %dist
> > variable, so %{?dist} evaluates to nothing. If you're doing rebuilds of your
> > packages with no source changes from one release of openSUSE to the next, or
> > rebuilding for new Tumbleweed snapshots, you're going to get collisions all
> > the time, and builds will just fail because the NVR already exists.
> >
> I think ELN won't have this problem (at large scale) because it will inherit
> sources from Fedora where any new Fedora build has a bumped release for the
> reason you described. It will resemble more a shadow Koji for the secondary
> architectures.
>
> But you are right that funny times can come when an ELN build screws things and
> ELN people will have to not only untag it but also delete it from the NVR index so
> that it can be rebuilt again with the same NVR. Fedora people weren't happy if
> they had to add a dummy release bumps just only because of ELN.
>

If the goal is to minimize impact on everyone else by ELN work, having
this versioned makes sense because it prevents very annoying
disruptions later on.

> > This is utter chaos and you *really* don't want that problem on your
> > hands. Having the freedom to do a rebuild cycle for ELN whenever you
> > want to rebootstrap to a new major without changing sources is a
> > hugely valuable thing to be able to do.
> >
> I think they will just throw it away and start from the scratch. At the end
> they would like to rebuild all the packages with the new configuration.
>

I'm pretty sure that nobody is going to let them delete everything
from Koji to redo it. Unless they were spinning this up in a shadow
Koji rather than the main one, which I don't think is the intent here.



-- 
真実はいつも一つ!/ 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




[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