That sounds a lot easier than what I’ve been trying to do; do you
happen to have an example, or a script that shows your process so I can
use it as a starting point? I’ve never created any side tags before so
the whole process, as you described it, is new to me. :\
On 19 Sep 2024, at 15:46, Fabio Valentini wrote:
On Thu, Sep 19, 2024 at 5:20 PM Stephen Smoogen
<ssmoo...@redhat.com> wrote:
On Thu, 19 Sept 2024 at 11:07, Ron Olson <tachokni...@gmail.com>
wrote:
Hi all-
I’m trying to get Swift packaged for EPEL 10 but have an
interesting situation that I presume has been seen before, so am
hoping for some guidance.
Since 5.9 Swift has required a previous version of Swift to build;
5.8 is the last version that builds by itself. Now I’d like to
package Swift 6 for EPEL 10, but because no previous version of
Swift exists, I think what I have to do is build 5.8, while also
applying new patches because of versions of things like Python that
weren’t an issue when 5.8 was originally built. Once 5.8 is
hopefully built and available on EPEL 10, then I can build Swift
5.10, then build Swift 6.
Am I doing this workflow correctly? When packages depend on previous
versions of the package do folks do what I’m doing and basically
go back to the beginning and move forward until the latest version
can be built? And would I have to start all over again with EPEL 11,
12, etc.?
In the past, there are a couple of ways to bootstrap a software
language:
1. Do the work the long way like you list and build a bunch of things
over and over from scratch until you get the one you need. Do this in
a sidetag(?) so it doesn't affect (infect?) the main release.
2. Work with releng to set up the appropriate 'side area' in koji
which will check in the version of swift from Fedora 39 or 40 which
meets your needs. Use this to build your first level of bootstrap.
Have that version 'checked out' and rebuild the bootstrap to make
sure it is viable. Then build the final one with the bootstrap.
3. Use various rpm tricks to build a bootstrap of a language compiler
which can be used as a minimal viable compiler. This is dependent on
the language but some will allow you to build something which is just
enough to rebuild itself at a later stage.. put in the rules so that
a 'bootstrap' flag can be sent and it will build that version. Use
that to build the next stages.
4. Combine 1,2,3 because the language is so special it needs all of
them. [I see you older versions of Rust]
I don't know if this would be applicable to swift too, but the way I
handled bootstrapping the Rust crate stack in EPEL 10 was by
- creating a side-tag for epel10
- tag rawhide builds into the side-tag as necessary to resolve the
bootstrap problem
- rebuild things from the epel10 branch
- untag all tagged-in rawhide builds again
- submit side-tag as update via bodhi
Unless I miss something (like, is the swift package fundamentally
different on EPEL?), that should work here, and it would involve many
fewer steps than the other solutions.
Fabio
--
_______________________________________________
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
