Package Details: abseil-cpp 20200923.2-3

Git Clone URL: https://aur.archlinux.org/abseil-cpp.git (read-only, click to copy)
Package Base: abseil-cpp
Description: Abseil Common Libraries (C++)
Upstream URL: https://github.com/abseil/abseil-cpp
Licenses: Apache
Submitter: akstrfn
Maintainer: akstrfn
Last Packager: akstrfn
Votes: 3
Popularity: 0.92
First Submitted: 2018-08-21 19:08
Last Updated: 2020-11-16 13:10

Dependencies (1)

Required by (1)

Sources (1)

Latest Comments

1 2 3 4 Next › Last »

akstrfn commented on 2020-11-16 12:45

Thanks for the reply and better suggestion on how to approach this problem TIL about makepkg --ignorearch. I definitely forgot about custom user repos so I see now that this breaks some people's workflow hence I was very wrong my with solution, which I thought does not harm in essence (except for raising few warnings). I will update all my packages that build architecture dependent binaries to specify arch correctly.

You solve this by writing correct PKGBUILDs, advising users to use --ignorearch if needed, and if you still don't think this solution is correct, submitting a makepkg bug report.

I guess ignoresearch is good enough albeit not perfect solution. I did think (albeit shortly) how pkgbuild could be amended to include more information about described issue but I did not have any good idea so I chose 'any' as solution.

All literally broken packages in the AUR are a problem, but I can only intercede in the ones people complain to me about, because those are the ones I'm aware of. This is not a defense for doing the wrong thing.

I was not defending anything, I was just very perplexed how come such a small issue raised so much fuss for a package that works. Its almost trivial to find python packages that have platform specific binaries in aur that are labeled as "any" and I never saw people so loundly complaining about the rules (maybe I didn't look enough...). Plus, there is literaly only one package depending on this package and even that package is usually used from git version afaik. So the whole discussion revolved around "the rules" ending up with rude demands.

Anyhow my solution was bad and your suggestions make more sense. Sorry for wasting your time.

eschwartz commented on 2020-11-16 12:03

arch=('x86_64') suffices, makepkg --ignorearch if users want to build on ARM. As the wiki already pointed out, it is up to maintainers to choose to formally support additional, non x86_64 architectures and you don't have to do wild things no one ever suggested like "listing every arch gcc can cross compile to".

pacman already incorporates the fact that binaries successfully compile on a diverse range of CPU architectures. Since pacman only cares about binary packages, it incorporates this fact by reading the arch tagging that makepkg applied.

makepkg does not have a grammar for "arch is '.*' but don't manually list them, and it isn't 'any' either because each of the infinite arches is different". Why? Because no one has truly needed this, or, to my memory, requested it. And makepkg --ignorearch works fine.

Either way, you don't "solve" this problem by writing a PKGBUILD that incorrectly generates -any.pkg.tar.zst binary output on one machine, but if added to a custom user repo via e.g. aurutils refuses to work on the rpi in the other room.

You solve this by writing correct PKGBUILDs, advising users to use --ignorearch if needed, and if you still don't think this solution is correct, submitting a makepkg bug report.

Additionally, I'm very currious why is this such as problem when there is plethora of literaly broken packages in AUR.

All literally broken packages in the AUR are a problem, but I can only intercede in the ones people complain to me about, because those are the ones I'm aware of.

This is not a defense for doing the wrong thing.

akstrfn commented on 2020-11-16 09:40

The rules? These attacks and demands are getting ridiculous.

I believe I gave a well reasoned explanation why there is 'any' as a workaround but I'll repeat. It's an omision that pkgbuild system can not inform a user that package works on different arch's as long as there is a requested compiler/interpreter available on a given system. But arch official repo's do not have to care about it since only x86 is supported.

Rust and (and I believe go) binaries are static with built in package manager support so they basically work everywhere where the compiler is available. Python as an interpreted language is a prime example of how 'any' does not work because there are many packages that will not work on different arch's without a rebuild. Heck a lot of python dev's dont even know the difference. Since you work on pacman you can decide by yourself if this makes sense and perhaps come up with a solution that can incoporate the fact that nowadays many packages only depend on the compiler/interpreter so they by default work on any platform where they are present.

Clearly the context is important and it is important if the package is in aur, I've seen the "package is in AUR" pulled up as argument many times before by TU (likely you as well). Most common example is base-devel not being referenced in pkgbuild's.

Since you can also just erase the package, remove me as a maintainer, move the package to community I'm not sure why you even bother writing for such a small issue? Since anyway, it's not gonna be the first time that TU's do something without notification... Additionally, I'm very currious why is this such as problem when there is plethora of literaly broken packages in AUR.

And no, I will not accept threats to comply with the "rules". If you have suggestion for some actual solutions I'm listening. This is the last threat request that I am responding to and the only reason I replied this time is because I value your techical opinion (your approach, not so much) so I might learn something.

eschwartz commented on 2020-11-16 04:17

akstrfn,

You're on extremely thin ice. Speaking with my Trusted User hat on, I find it completely unacceptable that you:

  • know the rules being referenced

  • reject them by saying "The arch guidelines are not suitable here."

The AUR is not an exception to the rules. The rules exist to enforce standards in the AUR where quality control is a known issue.

You MUST obey the rules about proper use of arch=(). No ifs, ands, or buts.

akstrfn commented on 2020-11-15 21:35

Thx, I've disabled them but it seems that -DBUILD_TESTING was not necessary.

mortymacs commented on 2020-11-15 11:54

Please disable tests on the compilation step by:

-DABSL_RUN_TESTS=OFF \
-DBUILD_TESTING=OFF \
-DABSL_USE_GOOGLETEST_HEAD=OFF \

ayekat commented on 2020-10-27 22:22

@akstrfn Whether or not the PKGBUILD is hosted on the AUR is completely irrelevant; the arch field applies to the built package (i.e. on which architectures the package can be installed). Unless your PKGBUILD somehow magically results in a package that contains architecture-independent .so files, any is therefore incorrect.

The correct way to declare that a package works on x86_64, i686 and arm is to state each of them in the arch array.

akstrfn commented on 2020-08-21 16:00

Sorry, no.

solstice commented on 2020-08-21 15:58

We don't care how you see it. Just follow the guideline, and stick to it.

akstrfn commented on 2020-08-21 15:47

@solstice Funny, if you actually read only the part that you posted it matches what I was saying however if you continue to examples we have a divergence... That first sentence is exactly how I see PKGBUILD's from AUR.