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 ssmoogen@xxxxxxxxxx wrote:
On Thu, 19 Sept 2024 at 11:07, Ron Olson tachoknight@xxxxxxxxx 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:
- 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.
- 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.
- 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.
- 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@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, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
