Talk:Arch package guidelines

From ArchWiki
Jump to navigation Jump to search

Fields order

Arch_Packaging_Standards#Package_etiquette states: "It is common practice to preserve the order of the PKGBUILD fields as shown above." But this is not true. Common practice is to use /usr/share/pacman/PKGBUILD.proto as a template, and the order of fields in that prototype has a far greater influence on packages in the wild than this page. This page should edited to reflect the current state of PKGBUILD.proto. Perhaps this page should state: "It is common practice to order PKGBUILD fields so they match the order of fields in PKGBUILD.proto. Ichimonji10 (talk) 14:32, 19 October 2013 (UTC)

Punctuation in PKGBUILD

What is the official guidance regarding ending a pkgdesc in a period or using commas and English prose punctuation in general?

[Link] to discussion thread.

Graysky (talk) 15:17, 14 June 2013 (UTC)

Package naming

  • Package names should consist of alphanumeric characters only; all letters should be lowercase.
This is a guideline, but I see some packages with hypens and underscores (tesseract-data-chi_sim), dots (gstreamer0.10), plus (libxml++) and even at-signs (kde-l10n-ca@valencia). A package with uppercase name is libreoffice-bn-IN. According to the makepkg source, the allowed chars are: [:alnum:]+_.@-. Lekensteyn (talk) 22:38, 1 February 2014 (UTC)
"alphanumeric characters only" rule is ridiculous, 85% of official packages break this rule. I think it should be changed to allow hypens. It makes package names more readable. In regards to other characters, the + sign breaks AUR search (example, should be escaped). axper (talk) 11:19, 11 May 2014 (UTC)
  • Package names should NOT be suffixed with the upstream major release version number (e.g. we don't want libfoo2 if upstream calls it libfoo v2.3.4) in case the library and its dependencies are expected to be able to keep using the most recent library version with each respective upstream release. However, for some software or dependencies, this can not be assumed. In the past this has been especially true for widget toolkits such as GTK and Qt. Software that depends on such toolkits can usually not be trivially ported to a new major version. As such, in cases where software can not trivially keep rolling alongside its dependencies, package names should carry the major version suffix (e.g. gtk2, gtk3, qt4, qt5). For cases where most dependencies can keep rolling along the newest release but some can't (for instance closed source that needs libpng12 or similar), a deprecated version of that package might be called libfoo1 while the current version is just libfoo.
  • Package versions should be the same as the version released by the author. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). Version tags may not include hyphens! Letters, numbers, and periods only.
This rule needs to get more stricter. Having a slash in the version breaks filenames. For craziness, I tried setting up a pkgver containing all characters from 0x01 to 0xff which makes makepkg throw a Bash syntax error. The current packages have versions matching {{ic}[[alnum:]._+~]+} (and a colon for epoch, a hypen for pkgrel). What about limiting to those characters? Debian has a similar set, see their policy docs Lekensteyn (talk) 22:38, 1 February 2014 (UTC)
  • Package releases are specific to Arch Linux packages. These allow users to differentiate between newer and older package builds. When a new package version is first released, the release count starts at 1. Then as fixes and optimizations are made, the package will be re-released to the Arch Linux public and the release number will increment. When a new version comes out, the release count resets to 1. Package release tags follow the same naming restrictions as version tags.
  • Why is there no mentioning of suffixes for different build sources, such as vcs sources (-git, -hg, …) or binary distributions (-bin)? IMO this is an important part of the package naming conventions in AUR. Fordprefect (talk) 13:43, 10 May 2016 (UTC)
Some of the information is sequestered into the AUR page's FAQ and other places, but I have a proposal to bring it together (and add some additional conventions). Since this page already has a section on package naming conventions, it would integrate well here. Unfortunately, as this is a protected page, I wouldn't be able to make the edits myself. quequotion (talk) 15:29, 23 February 2019 (UTC)
Here's a whole-page draft of what that might look like. quequotion (talk) 16:04, 23 February 2019 (UTC)

Proposal: Unofficial packages

  • Unofficial packages having extra features enabled and/or patches in comparison to their official counterparts should be named differently to express that. For example, a package for GNU screen containing the sidebar patch could be named screen-sidebar. Additionally the provides=('screen') array should be used to avoid conflicts with the official package and satisfy its dependents.
Comment: This rule is not relevant for the official repositories so it does not fit to this page. -- Lahwaacz (talk) 17:00, 16 March 2019 (UTC)
There's nothing indicating that the advice on this page is limited to official packages. On the contrary, I think we very much want these guidelines to apply to official packages, AUR packages, third-party repository packages, etc. Such that if ever someone comes looking to help with such a package on the forums or IRC, we can know right away if they are using official or unofficial packages (it should not be assumed the user will know the difference or the significance of it). quequotion (talk) 23:30, 16 March 2019 (UTC)
Yes, these guidelines apply to everything, but everything on this page should apply to official repositories as the least common denominator. Rules which are not common should belong elsewhere. -- Lahwaacz (talk) 08:12, 17 March 2019 (UTC)
That would leave this convention with nowhere to go, as it applies not only to AUR packages but third-party packages anywhere. How about prepending "Unofficial" to make clear that this convention applies to packages that are disqualified for inclusion in official repositories? quequotion (talk) 08:47, 17 March 2019 (UTC)

See also the various package guidelines pages for other naming conventions.

Is it acceptable for build() to start by removing directories?

I just downloaded a PKGBUILD whose build() function begins with the following:

find ./ -maxdepth 1 -mindepth 1 -type d  -exec rm -r {} \;

It seems to me that a PKGBUILD has no business doing this and that it is potentially dangerous. I admit that its danger will typically require people to do non-standard things and, arguably, things they would be better advised not to do anyway. But it still seems to me to invite trouble.

I don't remember seeing this in a PKGBUILD before but I can't find anything definitely ruling it out.

Is it acceptable for a build function to start by removing directories in this way? Is it safe?

--cfr (talk) 03:03, 27 February 2014 (UTC)

I'd argue that this is an acceptable thing to do, at least in some cases. As an example, consider Talend Open Studio DI: a single source file provides files for Windows, Linux, Mac OS, PowerPC (?) and Solaris. In response, the talend-open-studio-diAUR PKGBUILD simply removes them. Does removing those files invite trouble? Yes. But removing files seems like an integral tool in the package maintainer's toolkit, and plenty of other weird stuff happens in PKGBUILDs too. Ichimonji10 (talk) 02:20, 3 March 2014 (UTC)

Unique sources

The source array should only contain unique sources names if a shares source directory is used. This applies to most github download. You can use "${pkgname}-${pkgver}.tar.gz::" prependet to each source to make the filename unique. I am not allowed to edit the page, could someone please do so?--NicoHood (talk) 15:33, 16 December 2016 (UTC)

Add security standards

As we decided to use https and GPG wherever possible for PKGBUILDs this should be added here as well. A Link to the mailing list would be also nice. The usage of strong hashes could also be mentioned, but I assume some people will not like the idea. A Link to the discussion about the hashes could also help for everyone to get his own opinion. It should be also mentioned that maintainers still need to validate the content of the downloads and test the update. Another important point is to contact upstream for GPG signatures if they are not available yet. One can link to some templates/tutorials I made on --NicoHood (talk) 19:40, 16 December 2016 (UTC)

Forget about the checksums part, as it was already declined multiple times by the developers. For the rest, patches welcome. -- Alad (talk) 20:19, 16 December 2016 (UTC)
edit: see also User:Apg#makepkg:_replace_default_checksums -- Alad (talk) 15:21, 14 March 2017 (UTC)

Architecture Section not clear enough

The arch array depends "on which architectures it can be built on". This is okay but I believe it should be clarified that the program also needs to run and work on that architecture. I know it's a bit "obvious" but people who write interpreted programs may understand that they should put "any" in the arch array even if their program is not usable at all for some architectures. Cecton (talk) 07:14, 28 April 2017 (UTC)

How does fixing "built on" to "built for" prevent people from abusing any? That's a separate problem. Also, interpreted programs like scripts should use any, where do you think they shouldn't? -- Lahwaacz (talk) 08:39, 28 April 2017 (UTC)
There is that program (debtap in AUR) wrote in bash that converts deb packages to Arch Linux packages. Unfortunately the program works only for i386 and amd64 because it fetches Ubuntu repositories at some specific locations. So when you run it on an arm architecture it fails with a curl output saying 404 which is not user friendly at all. IMHO a package should be restricted to the architectures where it works but in the specifications here, the only requirement is that it compiles. Cecton (talk) 09:08, 28 April 2017 (UTC)
Actually it is better specified here: PKGBUILD#arch "If instead a package can be compiled for any architecture, but is architecture-specific once compiled, specify all architectures officially supported by Arch, i.e. arch=('i686' 'x86_64'). " Cecton (talk) 10:10, 29 April 2017 (UTC)

Since we no longer support i686 and the section had to be edited anyway, I tried to clarify the situation described above. I don't think it should include something like ".. and any other architectures the package builds/compiles/runs on", as we only support x86_64. None of the packages in the official repositories specify architectures besides 'x86_64' and 'any' (I think). Lonaowna (talk) 15:41, 13 January 2018 (UTC)

Maybe we should just do like we do for Licenses, and say "See PKGBUILD#arch". I think we explain in sufficient detail there. :) -- Eschwartz (talk) 03:26, 14 January 2018 (UTC)
Not saying it's a bad thing, but following this approach there wouldn't be much left of the official packaging guidelines... The purpose of the entire page should be rethought. -- Lahwaacz (talk) 09:41, 14 January 2018 (UTC)

/opt vs /usr/share

Should there be a clause here or somewhere about preferring /opt for big/self-contained AUR packages instead of /usr/share? Isn't there such a policy? —Dettalk 17:17, 21 May 2017 (UTC)

That's somewhat covered by the FHS. There's no reason to make it specific only to AUR, even official packages like cuda or vtk6 are installed into /opt. -- Lahwaacz (talk) 18:34, 21 May 2017 (UTC)
Do you mean that actual page? So sections like Arch packaging standards#Directories should really be replaced with a link there? —Dettalk 19:02, 21 May 2017 (UTC)
There you go, you even have the policy, so what's the point of this discussion really?? -- Lahwaacz (talk) 20:07, 21 May 2017 (UTC)
Alad, I'd appreciate it, if you didn't just come in and close an ongoing discussion. Anyway, so shouldn't that text be amended if that small piece is our official guideline? 1) Java is not installed in /opt (neither jre7-openjdk nor jre8-openjdk), 2) what is a "self-contained" package? Can it have e.g. icons and desktop files in /usr? I would hope so. —Dettalk 21:19, 21 May 2017 (UTC)
Det, you really need to improve the way you ask questions. We don't have telepathic powers like you might have, so there is no way we could have guessed from the first post that you want an explanation for a section that you linked in your second post. Please read the standard reference on this topic, How To Ask Questions The Smart Way.
Now back to the topic. You're right about Java, so I removed that example. There are multiple reasons to use /opt, most often it is because it may be too hard or even impossible to merge the software with the system's /usr hierarchy. For example the software might come with bundled libraries which may conflict with the system libraries, this is where the "self-contained" comes from. If you take a look at the content of the cuda package, you will see that manual pages, licenses and desktop files are installed into /usr/share.
-- Lahwaacz (talk) 07:17, 22 May 2017 (UTC)
Hmm. I don't think I was looking for an explanation to another article from the talk page of a different article. What "telepathic powers" that I "may have" have got to do with that, I've no clue. Also, I don't think I need patronisations about how to ask good questions. :-)
Anyway, as you can see from the flow of the conversation, first I thought there should be an AUR-specific instruction on /opt. Then you say no, and there's also a different site. Then I ask about that other general one I found, different article, which is very cryptic, a bit out-of-date, and maybe that's the reason that it is. Then you respond, well exactly, that's what we already got, so why ask in the first place, and Alad closes the conversation?
Right? On the issue, I can see cuda has its stuff elsewhere besides /opt. However, the point is, why isn't it explained in that article? Why isn't your explanation in the article? Also, it currently says "large self-contained". What is the definition of large? Smaller ones belong in /usr?
I don't need that explanation, the article needs it. People reading for the first time need it. Right? —Dettalk 08:24, 22 May 2017 (UTC)

Directories -- Why shouldn't /srv be used?

I'm updating the AUR package for the cyrus-imapd package, and noticed that this guideline states that the /srv directory should not be included in the package. Persistent application data should be placed in /var/lib/{pkg}. I'm wondering if there is a good reason for this? From long experience, /var tends to include a lot of rapidly changing ephemeral data and often ends up on a (typically smaller and faster) OS disk partition. And in the past, mounting another partition to /var lead to timing issues. systemd has fixed the latter, but the former persists, and IMAP mail stores tend to grow quite large over time. As a result, I've adopted the convention of using /srv for data which is served out and which can grow in size indefinitely. Furthermore, this is precisely how the directory is intended to be used according to the FHS. So I'd like to put the IMAP user mail store in /srv/imap by default, and was planning to do so until I ran across this document. Sort of feeling like this specific instruction is out of date (but agree that the other directories listed shouldn't be used) Pgoetz (talk) 22:15, 13 March 2019 (UTC)

Adding to my own comment, for purposes of clarification. Again, from long experience, people find setting up an imap server to be complicated and intimidating, so it would be better to offer an a priori rational directory structure which needn't be modified after the fact. Pgoetz (talk) 22:20, 13 March 2019 (UTC)
> /var tends to include a lot of rapidly changing ephemeral data
Wrong. E.g. PostgreSQL and MariaDB store their database data, which are definitely not ephemeral, in /var/lib/. The /srv/ directory is intended for files which are directly served, such as static .html, not for files which have to be decoded or decrypted to assemble the served content. -- Lahwaacz (talk) 17:07, 16 March 2019 (UTC)

Package naming: Redundant bullet points (pkgver, pkgrel)

The bullet points regarding pkgver and pkgrel are highly redundant with the content on the PKGBUILD page. They are also not technically part of a package's "name". I would remove these from the page. quequotion (talk) 14:35, 15 May 2019 (UTC)

Systemd Services

Can we get a clause in here that says system services should not be enabled or started automatically at the time of installation?

Greyltc (talk) 17:32, 2 June 2019 (UTC)

I don't think there is an official policy against enabling services.
There are official packages that statically enable services:
pkgfile -dg '/usr/lib/systemd/system/*.wants/'
Other packages enable services in the .install script, creating untracked files in the file system: FS#59334, FS#59335, FS#59336, FS#59337.
All of them should be using systemd.preset(5), but there's very little chance of that happening.
-- nl6720 (talk) 09:12, 3 June 2019 (UTC)
The chances of that happening would be greater if there were a policy statement about it on this page (or, perhaps, a systemd-specific guidelines page). quequotion (talk) 09:52, 3 June 2019 (UTC)
How about some words that say AUR packages should not do this? I was recently unpleasantly surprised when an AUR package I installed modified firewall settings and started up a systemd service listening for remote connections over my network. I'd like to get that package fixed so it doesn't do this, but so long as it agrees with the packaging guidelines here, then it seems I can't/shouldn't "fix" it. Greyltc (talk) 10:37, 3 June 2019 (UTC)
In theory, these guidelines are subject to change--if we get consensus here, and the attention of someone with authority to make changes. My vote is with you: packages (AUR or otherwise), should generally not enable systemd services on install. I might make exception for systemd itself, and perhaps other packages in core if it can be argued, reasonably, that their services are essential to the operation of a "standard" Archlinux installation. There's very little chance of enforcing that outside of the official repositories, but having it on a guidelines page would at least provide something authoritative to link package maintainers to if their packages enable services without the informed consent of users. quequotion (talk) 15:21, 3 June 2019 (UTC)
That's exactly my intention here. Get a rule on this page that says AUR packages shouldn't (in almost all cases) start services, then link to that rule as justification why the package should be changed. Greyltc (talk) 16:33, 3 June 2019 (UTC)
This page is not intended for AUR-only rules, they go to the Arch User Repository page. -- Lahwaacz (talk) 17:24, 4 June 2019 (UTC)
Although Greyltc would like to apply this policy to an AUR package, it is not an AUR-exclusive policy. I don't think packages in official repositories should necessarily enable their systemd units at install either. See proposal below. quequotion (talk) 19:51, 4 June 2019 (UTC)
You can either propose a straightforward AUR-specific policy with no exceptions and pretty solid chance of being accepted by the community, or a vague global policy with dozens of exceptions and practically no chance of being accepted by devs and TUs. The proposal below misses reality, because e.g. extra/pkgstats comes with a timer enabled by default and it is definitely not essential. For anybody (maybe except the devs and TUs), I think their proposed guidelines for this page need to reflect reality rather than try to enforce it. If you want to change how packaging is done in reality, do it by the means of bug reports and when there are sufficiently many of them accepted, feel free to propose a guideline for this changed reality. -- Lahwaacz (talk) 20:45, 4 June 2019 (UTC)
The whole premises of users trying to enforce policy on developers by modifying wiki pages is flawed at best. Besides, one developer already expressed their disapproval of this proposal on IRC. As stated above, we could hold this discussion for the AUR, but for the official repositories it makes no sense. Closing -- Alad (talk) 21:25, 4 June 2019 (UTC)
No one is challenging your authority. This is a protected page, it's not even possible. All we can do is ask to have the policy considered, and to discuss the merits and demerits of the policy itself, rather than the emancipation of the common user. quequotion (talk) 03:10, 5 June 2019 (UTC)
  • Would it be overwhelmingly difficult to implement?
Some packages would need to be changed; no one expects that to happen overnight. Lahwaacz points out one such package. Is it indicative of a larger number of other packages enabling non-essential services on install? or is this, in practice, already a custom most packages follow? I haven't done a complete audit of the ABS to prove either way; seems a little premature to declare that the proposal "misses reality" unless either of you have already done such an audit. I can understand some exceptions, as stated above and below, but I wouldn't consider an exception for all core packages to be "dozens of exceptions", even if it means dozens of packages that is one rule.
  • Do we need this policy at all?
Seems like a good idea to me: don't start daemons or open sockets that may end up doing things like eat up cpu or open ports without informed consent of users. Is it crucial to the future of Archlinux? At the moment, probably not; depends on how many packages may have systemd units in the future.
On the other hand, it could be more problematic than I had considered. I don't know how valid this train of thought is, but it occurred to me that, as Arch has a policy of sticking as close as possible to upstream, if an upstream install script would enable services, the Arch package of that software probably has to as well. Also, in the case of AUR pakages in particular, Arch User Repository recommends to carefully read PKGBUILDs before installing packages to avoid such surprises. In any case, I'm not going to reopen the discussion--if this doesn't belong here, or on a systemd-specific guidelines page, it makes even less sense to put it on the AUR page (it would be rather nonsensical to make AUR policies more restrictive than those on the official repositories). quequotion (talk) 13:07, 5 June 2019 (UTC)

Proposal: Policy on systemd unit activation

  • Packages should not enable systemd units on install unless they are considered essential to the operation of a standard Archlinux installation, such as those in core packages.

^this proposal is beautiful and it has my support (however unimportant that may be)! Greyltc (talk) 16:30, 4 June 2019 (UTC)