On Fri, 2022-03-11 at 15:31 +0100, Fabio Valentini wrote:
> On Fri, Mar 11, 2022 at 8:41 AM Leigh Scott <leigh123linux@xxxxxxxxx> wrote:
> >
> > > On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
> > >
> > > Why isn't this as simple as:
> > >
> > > 1) Create an f37-multilib-build build tag with all supported arches +
> > > i686,
> > > and an f37-multilib{,-candidate} build targets to use it (with
> > > destination tag
> > > of f37-updates-candidate);
> > >
> > > 2) Drop i686 from f37-build tag;
> > >
> > > 3) Maintainers of wine and its deps etc. opt-in to i686 with a
> > > package.cfg:
> > >
> > > [koji]
> > > targets = f37-multilib
> > >
> > > (Yes, that would have to be updated after branch point, but that could
> > > possibly be automated.)
> > >
> > > 4) Everyone else leaves their spec files alone, no need to add
> > > ExcludeArch:
> > > i686.
> > >
> > > Would that work?
> >
> > That works ok for rpmfusion.
> >
> > https://koji.rpmfusion.org/koji/taginfo?tagID=483
> >
> > fedpkg could be adapted as well, see
> >
> > https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L187
>
> This might work for RPMFusion, but only because you have a limited set
> of packages, and because you can rely on the Fedora buildroot and
> dependencies always to be there.
> For Fedora itself, we do not have that luxury. We would need to know
> the packages that are needed to build and maintain the base buildroot
> plus everything needed to build multilib packages. As I said, this is
> not so easy. And then we're back to modifying (adding config files)
> all packages that need to be included (or maintaining a hard-coded
> list of required packages in fedpkg), so you don't gain anything at
> all, compared to the simple opt-out mechanism from this Proposal.
I don't see the opt-out as being "simple" at all, as IIUC all it would take is
one maintainer not paying close enough attention to reverse dependencies to
break the i686 buildroot. Not to mention that it ends up polluting the vast
majority of packages with a spec file change that isn't technically accurate
(since the package *could* be built for i686, we've just choosing not to, and
the proper place to express that is in the build tag's arches).
Since the number of packages actually needed for i686 -- wine and its deps,
plus deps for those RPM Fusion i686 library packages, it seems -- should be a
small minority of the entire distribution, it should be those where the
changes are made. Doesn't it make more sense to special-case the exception
rather than the rule, as it requires fewer changes? (FWIW IMO package.cfg
files should be better than hardcoding a list in fedpkg, as the former doesn't
require the lag time involved in pushing an update when the list changes.)
It also avoids this becoming a piecemeal change, which will likely drag on for
years if left to individual maintainers.
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
