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 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:
>>
>> * The DistTag should be versioned. Either .eln.elX (e.g. .eln.el9),
>> .elnX (e.g. .eln9), or just plain .elX (e.g. .el9).
>> * Likewise, I think the Koji tags should be versioned too.
>>
>> 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.

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.

And honestly, I expect the ELN tree to exist for a long time once it's
in Fedora. So some of this is also planning for a future where we
always have Fedora ELN along with Rawhide and regular Fedora stable
releases.

What I'm confused about is the hangup with versioning the ELN tree.
Why is this a problem?

>
>>
>> Finally, there is no adequate explanation for why ELN content can't go
>> out to the mirrors like Rawhide content does. I'd vastly prefer that
>> simply to have similar levels of availability as consumers of ELN
>> content. I would prefer seeing it go to the mirror network like
>> everything else.
>
>
>
> It’s not so much that it *cannot* as that we are trying not to overload the mirror network with content not useful to non-developers.
>

Unless you plan to get Red Hat to do CDN delivery of ELN, I think
you're going to want it on the mirror network anyway. Ultimately,
contributors like myself need to be able to *use* the content, and not
having it delivered via the mirror network means that it's going to be
painful for a large cross-section of contributors and developers.


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