[arch-dev-public] Starting x86_64_v3 port

[Filipe Laíns]

On Sat, 2022-01-29 at 11:45 +1000, Allan McRae via arch-dev-public wrote:
> On 29/1/22 11:28, Morten Linderud via arch-dev-public wrote:
> > On Sat, Jan 29, 2022 at 11:22:32AM +1000, Allan McRae via arch-dev-public
> > wrote:
> > > On 29/1/22 11:13, Morten Linderud via arch-dev-public wrote:
> > > > On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via arch-dev-
> > > > public wrote:
> > > > > Is there any particular objection to requiring packagers upload both
> > > > > architectures?
> > > > 
> > > > I'm personally not really motivated doing the required builds. We have
> > > > an
> > > > underdeveloped infrastructure which hasn't changed since we abandoned
> > > > i686 5
> > > > years ago.
> > > > 
> > > > I'd personally like to see more work on our build tooling before we
> > > > commit to
> > > > new architectures.
> > > 
> > > FYI, it is a single extra command.  Either of these will work...
> > > 
> > > offload-build --arch x86_64_v3
> > > extra-x86_64_v3-build
> > > 
> > > Nothing else changes for the packager.
> > > 
> > > Allan
> > 
> > I'll spend twice as long waiting for a package to build which increases the
> > time
> > spent packaging. Which again requires me to spend more time watching stuff
> > fly
> > by.
> 
> I have concerns if that is how you spend your time...  :)
> 
> > This also assumes people are capable of using the buildserver which is not
> > always the case either.
> > 
> > This wasn't great with i686, and I'm not sure why we'd find this acceptable
> > today?
> 
> What was not great with i686?  We managed two architectures for many, 
> many years.  The reason for removing i686 was to do with outdated 
> technology, not to do with build times or infrastructure.
> 
> Do you have objections beyond not wanting to package for both repos? 
> i.e. do you object to option C in my original email, where we have a 
> team to keep the repos in sync when package maintainers do not build both?
> 
> Allan

I think the issue is not that we don't want to package for both repos, but the
increased workload that places on us.

For example, the most painful packages to update for me personally are the cross
compilers (and other elements of the cross toolchains, but mainly the
compilers). This is something I am already struggling with, and adding a new
architecture will make it twice as painful.

https://archlinux.org/packages/?sort=&q=gcc&maintainer=FFY00&flagged=Flagged

This could have been implemented by making x86_64_v3 kind of an overlay over the
normal x86_64, but instead it is its hole new architecture requiring duplicated
builds for all packages, and not just the ones where it actually makes a
difference and/or the maintainer is willing to do it.
I don't think this proposal considers the impact it will have on our already
struggling staff properly, but alas, there's nothing I can do as the RFC was
accepted.
It will certainly deter me from adding a couple new packages to the repos, and
perhaps drop some, FWIW.

The best option seems B, or C, but I don't really understand how B is supposed
to work in practice. Isn't the new architecture is supposed to be in sync with
the current one? Because not doing so seems a little bit problematic, and I
don't see a way for this to work otherwise.

Anyway, I thank you for your time working on this, it is certainly valuable, I
am just unsure, and, admittedly, perhaps a little bit pessimistic, about how
this implementation impacts my commitment as an Arch packager.

My two cents are that adding a x86_64_v3 would be amazing if had already reached
the, still far, goal of having automated package builders. But we are not there
yet, so this introduces a lot of manual labor :/

Cheers,
Filipe Laíns
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220129/c8878967/attachment.sig>