Difference between revisions of "Talk:PKGBUILD"

From ArchWiki
Jump to: navigation, search
(move relevant to top)
m (missing space)
Line 20: Line 20:
 
:::::to:
 
:::::to:
 
::::::''Dependencies that are provided by other dependencies do not need to be listed.''
 
::::::''Dependencies that are provided by other dependencies do not need to be listed.''
:::::So, repetition, unnecessary chatter, and using phrases like ''"available options are A and B"'', instead of ''"you can do A but you can also go ahead and do B"'', etc.--'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 20:39, 5 February 2015 (UTC)
+
:::::So, repetition, unnecessary chatter, and using phrases like ''"available options are A and B"'', instead of ''"you can do A but you can also go ahead and do B"'', etc. --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 20:39, 5 February 2015 (UTC)
  
 
== Example? ==
 
== Example? ==

Revision as of 20:41, 5 February 2015

pkgdir

Re [1], how is "pkgdir" useless? It's used in nearly every PKGBUILD, make is very common too, unless I'm missing something... -- Alad (talk) 11:57, 5 February 2015 (UTC)

The difference is that pkgdir is not to be defined by the packager, so it does not make sense to describe it among variables defined by the packager. It is still described in Creating_packages#Defining_PKGBUILD_variables though. -- Lahwaacz (talk) 13:12, 5 February 2015 (UTC)
Hm, I see. I'd then suggest to change the introductory sentences,
This article discusses the variables used in PKGBUILDs. For information on the PKGBUILD functions, refer to Creating packages#PKGBUILD functions.
and
The following are variables that can be filled out in the PKGBUILD file
are ambiguous imo. -- Alad (talk) 13:22, 5 February 2015 (UTC)
Done. Is it good? --Dettalk 17:18, 5 February 2015 (UTC)
Works for me, thanks. But I'm having difficulties understanding [2] ... -- Alad (talk) 20:27, 5 February 2015 (UTC)
Yeah, I know, it was pretty difficult to try to summarize all that in one description, but it's basically changing things like:
It is not necessary to specify the version of the packages required. You do not need to list packages that your software depends on if other packages your software depends on already have those packages listed in their dependency
to:
Dependencies that are provided by other dependencies do not need to be listed.
So, repetition, unnecessary chatter, and using phrases like "available options are A and B", instead of "you can do A but you can also go ahead and do B", etc. --Dettalk 20:39, 5 February 2015 (UTC)

Example?

Should we have an example PKGBUILD or just separate use cases in each category? --Dettalk 17:58, 5 February 2015 (UTC)

I'd think the examples in /usr/share/pacman suffice. -- Alad (talk) 20:29, 5 February 2015 (UTC)
K. --Dettalk 20:39, 5 February 2015 (UTC)

Move similar/related sections into parent sections

I think it would be useful to move PKGBUILD#md5sums, PKGBUILD#sha1sums, PKGBUILD#sha256sums.2C_sha384sums.2C_sha512sums into a parent section (e.g. named "Checksums") and leave only information specific to each variable in its given subsection. All 3 of these sections contain redundant information as they obviously all deal with the same thing: checksums.

This would also be useful for the four dependency related sections (depends, optdepends, makedepends, checkdepends), considering the edits I made here.

Thoughts? Opinions?

-- Jstjohn (talk) 04:16, 11 January 2014 (UTC)

I see a problem in the fact that currently all the child sections of #Variables are actual variable names, while after your proposed change that wouldn't be true anymore. Now, I agree that we should try to find a way to avoid duplication of content, so I propose to split the whole #Variables section in several top-level sections, like #Generic_variables, #Dependency_variables, #Checksum_variables (and more if we can identify more groups). -- Kynikos (talk) 03:54, 12 January 2014 (UTC)
+1 for splitting -- Kycok (talk) 07:51, 24 May 2014 (UTC)
Done. --Dettalk 11:23, 5 February 2015 (UTC)

Split packages

This needs to be updated for split packages. Daenyth 22:55, 4 December 2009 (EST)

Done. --Dettalk 11:23, 5 February 2015 (UTC)

Variables/noextract about zip?

Isn't this information outdated? It seems bsdtar can now perfectly handle zip-files. --Paolo 11:03, 8 September 2010 (EDT)

This information is still in the wiki. libarchive/bsdtar do support zip files. Are there some corner cases that libarchive's bsdtar cannot handle properly?
-- Jstjohn (talk) 04:55, 11 January 2014 (UTC)
Done. --Dettalk 11:23, 5 February 2015 (UTC)

package description

Note: Do not follow this rule thoughtlessly when submitting packages to AUR. If package name differs from application name for some reason, inclusion of full name into description can be the only way to ensure that package can be found during search.

I never had trouble with pre-/postfixed application names so the note doesn't apply to this case. Does it? Slopjong 03:19, 11 July 2012 (CEST)

I think the note leaves the decision up to the maintainer, and it seems reasonable to me. If you're intentioned to discuss the guidelines for PKGBUILDs, this is not the right place, please post in the forums or the mailing lists. -- Kynikos (talk) 12:28, 11 July 2012 (UTC)
Done. --Dettalk 11:23, 5 February 2015 (UTC)