On Tue, 24 Jun 2025 at 09:45, Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Tue, Jun 24, 2025 at 09:25:23AM -0400, Stephen Smoogen wrote: > > On Tue, 24 Jun 2025 at 09:09, Petr Pisar <ppi...@redhat.com> wrote: > > > > > V Tue, Jun 24, 2025 at 08:25:09AM -0400, Stephen Smoogen napsal(a): > > > > I realized I wasn't clear on what I meant by a microOS. This would be > > > only > > > > the libraries and tools needed to run a specific utility on a 64 bit > > > kernel > > > > > > > Which itself is not a small project because the libraries and tools > need > > > to be > > > compiled with a compiler and built with a build system. > > > > > > Would Koji have to nurse i686 architucture and builders for it, or > would > > > a crosscompilation on x86_64 producing x86_64 RPM packages installing > i686 > > > ELF > > > files acceptable? Because the first, native approach would also involve > > > supporting Koji, Python, DNF, OpenSSH etc. in their native form. > > > > > > > > Oh quite agreed on this. There is a LOT of work involved to make it work > > and quite likely too much work.. but that work is what is being 'hidden' > by > > having it done as 'well its just another architecture and you can support > > it easily' that we have been giving i686 for a long time. > > If we only want to build a small subset of packages as i686, then > rather than doing it as an architecture in koji, IMHO, we could > consider doing it as cross-compiled target, creating sub-RPMs > from the native x86_64 package, as we do with the mingw packages > for example. That could potentially eliminate pretty all of the > rel-eng and infrastructure burden, and ensure package maintainer > burden is strictly confined to where its needed. > > Yeah I could picture it as something like: sig_x86_32_glibc.src sig_x86_32_gcc.src sig_x86_32_llvm.src sig_x86_32_mesa.src ... The versioning and updates would be up to the sig to deal with versus the main maintainer > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > > -- > _______________________________________________ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
-- _______________________________________________ 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
