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
