You are not logged in.

#1 2019-03-03 03:36:30

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 682
Website

Arch user repository FAQ integration and related proposals.

This did, as expected, escalate to edits on multiple pages.

Feedback's been sparse, particularly on the actual talk pages of the proposals (IRC feedback, however positive, doesn't count).

How about a thread to (unofficially) discuss these changes (being aware that only feedback on the wiki talk pages matters)?

There are some additional conventions for the protected page "Arch package guidelines"; see the "Package naming" section in this whole page draft.

The FAQ integration proposal is rather involved. The benefits are best illuminated by seeing its whole page draft.

Already transferred one makepkg error message to the Makepkg page.

Questions and suggestions welcome!

Last edited by quequotion (2019-03-15 11:36:40)

Offline

#2 2019-03-03 13:10:20

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 6,795

Re: Arch user repository FAQ integration and related proposals.

32-bit versions of packages should have the prefix lib32- and packages distributing both 32-bit and native versions should have the suffix -multilib. Use the suffix -x32 for packages that utilize the x32 ABI.

Not happy with the wording.
The whole multilib situation is rather complex and not described clearly anywhere in wiki afaik.
Have to think how it could be described better.


Multi-init booting with apg Openrc and systemd coexisting
Automounting : not needed, i prefer pmount
Aur helpers : makepkg + my own local repo === rarely need them

Offline

#3 2019-03-04 00:24:00

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 682
Website

Re: Arch user repository FAQ integration and related proposals.

Lone_Wolf wrote:

The whole multilib situation is rather complex and not described clearly anywhere in wiki afaik.

Valid point. We need a "32-bit package guidelines" to add to the list in "Template:Package guidelines". "Arch package guidelines#Package naming" isn't the right place to go into the details of what 32-bit packages are, but this section should link to a more detailed page.

I had also considered if this should be one, two, or three individual points:

 * 32-bit versions of packages should have the prefix lib32- and packages distributing both 32-bit and native versions should have the suffix -multilib.
 * Use the suffix -x32 for packages that utilize the x32 ABI.

or

 * Prefix 32-bit versions of native packages with [[32-bit package guidelines#lib32|lib32-]] 
 * Suffix [[split packages]] distributing both 32-bit and native versions with [[32-bit package guidelines#multilib|-multilib]].
 * Suffix packages that utilize the [[Wikipedia|x32 ABI]] with [[32-bit package guidelines#x32|-x32]].

Last edited by quequotion (2019-03-04 00:25:20)

Offline

#4 2019-03-04 04:17:40

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,853

Re: Arch user repository FAQ integration and related proposals.

I fail to see why we need a dedicated page to describe three bullet points on the topic of *naming* two *different* types of packages.

I also fail to see why a -multilib package would be needed at all, since it is generally considered better not to duplicate things, and repackaging the native component of a software product together with the separate lib32 version, is exactly that. Maybe instead we could have a guideline saying *not* to do it?


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2019-03-04 08:04:15

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 682
Website

Re: Arch user repository FAQ integration and related proposals.

eschwartz wrote:

I fail to see why we need a dedicated page to describe three bullet points on the topic of *naming* two *different* types of packages.

As do I. "32-bit package guidelines" page would serve the same purpose as pages like "Electron package guidelines" or "Nonfree package guidelines". If there were a "32-bit package guidelines" page, with its own "Package naming" subsection (as some in this list have), listing these conventions on the "Arch package guidelines" page becomes redundant. The  "32-bit package guidelines" page should also explain in further detail what 32-bit packages are and how to make them properly, eg how to ensure a 32-bit build doesn't interfere with a native version, gets cross-compiled correctly, and provides (only) the necessary files.

eschwartz wrote:

I also fail to see why a -multilib package would be needed at all, since it is generally considered better not to duplicate things, and repackaging the native component of a software product together with the separate lib32 version, is exactly that. Maybe instead we could have a guideline saying *not* to do it?

For a while I was maintaining several lib32 and multilib packages as part of mmug--a project in which I attempted to resolve every lib32 build-dependency to compile pcsx2 (at the time 32-bit only) against gtk3-ubuntu-git (forward ported ubuntu's patches), sdl2-hg, and wxgtk-gtk3-no-stl-no-sdl-svn--let's not get into why.

What I found was that for packages one is going to build from source--especially upstream development packages--it's better to use a split package, download the source once, and build it twice. It wouldn't be necessary for packages provided in the repositories if there were (properly packaged) native and 32-bit packages available.

At the time I had to create a number of my own 32-bit packages, using other people's packages as my only guide. Many official 32-bit packages were missing architecture-specific includes, pkgconfigs and executables (ie, they could not serve as build or runtime dependencies for other 32-bit packages); or had configurations that deviated from their native counterparts (in ways such as having not been updated in a longer time than the native package, ignoring a bug or feature that was explicitly handled in the native package, etc.); and that several packages were either ignoring or overriding CFLAGS, CXXFLAGS, and/or LDFLAGS (to the point that some "lib32" packages would build a native package unless built in a "clean" 32-bit chroot).

Edit: I created a draft page. I also have another slew of proposals, in particular that creating this page could clean up a mess on the makepkg page; that any non-redundant parts of the 32-bit clean chroot method should merge into the main clean chroot page; and that the VCS package guidelines could use some organizing.

Last edited by quequotion (2019-03-04 15:20:44)

Offline

#6 2019-03-05 13:27:41

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 6,795

Re: Arch user repository FAQ integration and related proposals.

Quequotion,  you may have opened a can of worms without realising it.

There are multiple approaches to building lib32 (even in offical repos) , autools / meson / cmake all handle such builds differently.

Even the question whether lib32 pacakges should be seen as a cross-compile builds or as native builds (with some special settings) doesn't have an answer most agree on.


I suggest you stick to package naming and add examples / reasons what a suffix stands for.

example for the multilib suffix :

gcc-multilib was used for gcc on x86_64 architecture to distinguish between compilers that could only built 64-bit binaries or both 64 and 32 bit binaries
It's easy to confuse this with the multilib and multilib-testing repositories.

Currently there are NO packages in repos with this suffix, aur maintainers should think very hard before using it.

Last edited by Lone_Wolf (2019-03-05 13:28:13)


Multi-init booting with apg Openrc and systemd coexisting
Automounting : not needed, i prefer pmount
Aur helpers : makepkg + my own local repo === rarely need them

Offline

#7 2019-03-05 16:13:22

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 682
Website

Re: Arch user repository FAQ integration and related proposals.

Lone_Wolf wrote:

Quequotion,  you may have opened a can of worms without realising it.

Actually, I was kind of expecting to open one (same with the AUR FAQ). I have no idea, for example, how x32 packages are compiled, and I know there are all kinds of other build systems to account for--all of which have varying degrees of standardization in this regard (ergo, it is difficult to say "pass this flag to configure" when I know that not every package is certain to have that flag accounted for--even if it is a flag nearly every other package everywhere does support). I have not forgotten the series of nightmares that was maintaining mmug--Cmake, the build obfuscation system, is particularly insidious: there doesn't seem to be much standardization of parameters; many cmake build scripts discard the CFLAGS specified by makepkg (not only when making "Release" builds).

Lone_Wolf wrote:

Even the question whether lib32 pacakges should be seen as a cross-compile builds or as native builds (with some special settings) doesn't have an answer most agree on.

I don't mind digging for the semantics to avoid the conflict in the page content. There's probably a way to describe them that would be neutral in that debate.

Lone_Wolf wrote:

I suggest you stick to package naming and add examples / reasons what a suffix stands for.

I think we do need the general "32-bit package guidelines" page though, for precisely the issues you bring up: there's a lot of vaguery to be cleared up; a plethora of options to suggest standards for; the information isn't available anywhere else, etc. I would very much appreciate help with this task. Don't be shy to edit one of the draft pages or make a suggestion on a talk page.

Lone_Wolf wrote:

Currently there are NO packages in repos with this suffix, aur maintainers should think very hard before using it.

I get that you want to tell readers that packages with a -multilib suffix can never be official packages, but I would rather say it outright than give a scary warning like this--if it needs to be said at all.

Edit: Added (and reworded) your suggestion as a Template:Note.

Last edited by quequotion (2019-03-05 16:32:26)

Offline

#8 2019-03-14 23:13:53

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 682
Website

Re: Arch user repository FAQ integration and related proposals.

Made some updates to "32-bit package guidelines", and rewrote the 32-bit clean chroot method as a new subsection for "DeveloperWiki:Building in a clean chroot".

The developer wiki page is protected, so I have to ask for help there. I may go ahead with the "32-bit package guidelines" proposal in the next week or so unless I hear some objection (removes a problematic subsection from "Makepkg" and adds a link to "Template:Package guidelines").

Still need talkpage feedback on the AUR FAQ proposal.

Offline

#9 2019-03-15 12:08:13

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 6,795

Re: Arch user repository FAQ integration and related proposals.

I don't see a way to correct the "32-bit package guidelines" page without explaining a lot.
I'll start working on a document to describe how lib32 and the multilib repo came to be.

Should i post that here, on my wiki talk page or email it to you, quequotion ?


Multi-init booting with apg Openrc and systemd coexisting
Automounting : not needed, i prefer pmount
Aur helpers : makepkg + my own local repo === rarely need them

Offline

#10 2019-03-15 17:07:17

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 682
Website

Re: Arch user repository FAQ integration and related proposals.

Lone_Wolf wrote:

Should i post that here, on my wiki talk page or email it to you

Here would do, but I'd most appreciate it if you could post any input for the proposal on it's talk page. Collaboration in this effort is very much welcome. If you have a lot to explain, please do.

Offline

Board footer

Powered by FluxBB