Re: PKGBUILD review request for displaylink-runit
Le 21/10/2023 à 14:48, Lone_Wolf a écrit : On 21-10-2023 10:05, Robin Candau wrote: As such, a package specifically made for derivatives (like this one, made to be used with the runit init system) is not allowed on the AUR. On the other hand runit is available from aur and archwiki describres how to use it alongside systemd . Eric, if your package will work on archlinux with runit running as PID 1 it would not violate any AUR rules. Indeed, thanks for the precision. I initially replied that because Eric specifically said coming from Artix (which isn't covered by the AUR), but if the package indeed works with vanilla Arch with the above condition, then it would be okay. Lone_Wolf -- Regards, Robin Candau / Antiz OpenPGP_0xFDC3040B92ACA748.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: PKGBUILD review request for displaylink-runit
On 21-10-2023 10:05, Robin Candau wrote: As such, a package specifically made for derivatives (like this one, made to be used with the runit init system) is not allowed on the AUR. On the other hand runit is available from aur and archwiki describres how to use it alongside systemd . Eric, if your package will work on archlinux with runit running as PID 1 it would not violate any AUR rules. Lone_Wolf
Re: PKGBUILD review request for displaylink-runit
Le 21/10/2023 à 00:39, Eric a écrit : Hi all, Hi Eric! I'm working on this PKGBUILD to provide a displaylink-runit service. I use an Artix based distro using runit instead of systemD as the init system. Before I publish this, please review this. [...] The AUR is meant for Arch Linux only (derivatives not included). As such, a package specifically made for derivatives (like this one, made to be used with the runit init system) is not allowed on the AUR. Hopefully you'll get the reviews and tests you're expecting, but if you want this package/PKGBUILD to be accessible publicly, you'll have to upload it somewhere else than the AUR. Best, Eric -- Regards, Robin Candau / Antiz OpenPGP_0xFDC3040B92ACA748.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: pkgbuild
Le 03/07/2023 à 22:20, james smith a écrit : one last question before adding it to the aur 1) can I have multiple emails for the maintainer so that I have a backup incase one email goes down 2) if the package goes to the main repos will I be the maintainer or will the person who brought it to the main repos be the maintainer 1) I'm not sure what you mean by "goes down". The email you filled in is a gmail address, I doubt it will often (if not "ever") go down :p If you meant that as if you ever decide to take that email down for any reason, then you can just update your email address in the PKGBUILD. Anyway, you /could/ have multiple emails in the PKGBUILD but the idea here is mostly to have a way to contact you directly if you're not responding to comments on the package's AUR webpage. One email address is fine :) 2) AUR packages are contributions made to the Arch Linux project and does not "belong" to the person who submitted or maintain them. In that sense, if an AUR package is moved to the main repos, the Arch package maintainer who did it becomes the new maintainer but you'll be listed as a "contributor" in the PKGBUILD. However, this cannot happen with that particular package because VCS/git packages are not allowed on the main repos, so "lemoa*-git*" won't ever go to the main repos. On Mon, Jul 3, 2023 at 7:12 AM Robin Candau wrote: Le 03/07/2023 à 07:00, james smith a écrit : Now after making those changes running it, it doesn't correctly git clone Neither source directory 'source' nor build directory 'build' contain a build file meson.build. and I believe this command is the culprit |printf "%s.r%s.%s" "$(git describe --tags --abbrev=0 | sed 's/^v//')" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"| because it git clones it "empty" as just the .git folder. Not all files https://bpa.st/XA5JI apologies for the redundant questions The culprit is that you copied the "meson setup" command from the wiki without actually adapting it to your case. The "source" and "build" statements in it have to be replaced by the actual "source" and "build" directory of the repo you're trying to build (notice how "source" and "build" are written in /italic/ in the wiki [1], indicating that they have to be adapted to your case). Also, you have to `cd` first to the cloned repo before launching build instructions. Finally, "libadwaita" should be an actual dependency (not simply a make one) I think. Here's a fixed PKGBUILD: https://bpa.st/BTXWE I allowed myself to also make some small "best practices" and "style" improvements to it as well: re-add the trailing ".git" at the end of the source, switch to sha256 instead of md5 (I know the checksum is skipped there, but better take the habit to use a stronger algorithm for the potential future), better indentation in functions, etc... [1] https://wiki.archlinux.org/title/Meson_package_guidelines#Using_meson_binary_directly -- Regards, Robin Candau / Antiz -- Regards, Robin Candau / Antiz OpenPGP_0xFDC3040B92ACA748.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: PKGBUILD for pissircd-git
Hey Ross! > Hey and hello, new here, and am wondering how to submit a patch to a > file... specifically the PKGBUILD for the package pissircd-git -- I've been > copying my own PKGBUILD file over during the generation of a package build > to avoid having it try to create a socket file in my home directory. Been > doing this for a long time, and am wondering how to make it more permanent. The most common way to get a patch to a maintainer is via email or as a comment on the AUR webinterface Most maintainers are happy to accept patches that fix things or nontrivial changes for an upgrade. cheers, gromit signature.asc Description: PGP signature
Re: pkgbuild
Le 03/07/2023 à 07:00, james smith a écrit : Now after making those changes running it, it doesn't correctly git clone Neither source directory 'source' nor build directory 'build' contain a build file meson.build. and I believe this command is the culprit |printf "%s.r%s.%s" "$(git describe --tags --abbrev=0 | sed 's/^v//')" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"| because it git clones it "empty" as just the .git folder. Not all files https://bpa.st/XA5JI apologies for the redundant questions The culprit is that you copied the "meson setup" command from the wiki without actually adapting it to your case. The "source" and "build" statements in it have to be replaced by the actual "source" and "build" directory of the repo you're trying to build (notice how "source" and "build" are written in /italic/ in the wiki [1], indicating that they have to be adapted to your case). Also, you have to `cd` first to the cloned repo before launching build instructions. Finally, "libadwaita" should be an actual dependency (not simply a make one) I think. Here's a fixed PKGBUILD: https://bpa.st/BTXWE I allowed myself to also make some small "best practices" and "style" improvements to it as well: re-add the trailing ".git" at the end of the source, switch to sha256 instead of md5 (I know the checksum is skipped there, but better take the habit to use a stronger algorithm for the potential future), better indentation in functions, etc... [1] https://wiki.archlinux.org/title/Meson_package_guidelines#Using_meson_binary_directly -- Regards, Robin Candau / Antiz OpenPGP_0xFDC3040B92ACA748.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: pkgbuild
/Transferring OP's reply to the proper mailing list/.
On Sun, Jul 2, 2023 at 6:59 PM Robin Candau wrote:
Le 02/07/2023 à 04:20, james smith a écrit :
I am trying to package this https://github.com/lemmygtk/lemoa
this is my pkgbuild any tips on how to improve it before I send
it to aur is appreciated
Hi James,
_/Quick note before reviewing your PKGBUILD:/_
/When asking for a review, try to make your PKGBUILD publicly
readable somewhere (by posting it in paste service for instance,
like https://bpa.st/ or https://gist.github.com/). This is way
easier to track as the discussion progresses and way more "trust
worthy" than an attached file sent to a mailing list.
//For everyone's context, here's the initial PKGBUILD provided for
a review:/
https://bpa.st/TXEW2
In it's current state, your PKGBUILD won't work and needs some
modifications and improvements.
Here's what I can list after a quick review:
- The comments at the top provided by the PKGBUILD example file
should be removed.
- You can remove variables/arrays that are empty/unused in your
PKGBUILD (epoch, groups, checkdepends, etc...).
- Consider filling out the maintainer info at the top of the
PKGBUILD. This isn't mandatory but it is recommended and appreciated.
- The pkgname you chose refers to a VCS package ("lemoa*-git*").
If you indeed want your package to be a VCS package (meaning that
it relies on the latest upstream commit instead of a specific
tag/release) then you have to adapt your PKGBUILD accordingly with
a proper "pkgver()" function [1].
Otherwise, switch your "pkgname" to "lemoa" and update the rest of
the PKGBUILD accordingly.
- 'GNU' isn't a valid license. The correct license for "lemoa"
currently is 'GPL3' [2]. See also the license section of the
PKGBUILD wiki page for more information [3].
- The 'Gtk' package listed in the "depends" array isn't a valid
package. "Lemoa" seems to depends on GTK-4 [4] which can be
installed via the "gtk4" package in Arch [5].
- Upstream documentation also lists "rust, cargo and pkg-config"
as "Build dependencies" [4]. According to that, you should add the
"cargo" package (which also provides "rust") to your "makedepends"
array.
However, you don't have to explicitly list the "pkg-config"
package (provided by the "pkgconf" package in Arch [6]) because it
is a member of the "base-devel" meta-package [7] which is assumed
installed during build-time [8].
- The "install" variable expects the name of an optional
".install" script used to perform tasks before or after the
install, the upgrade and/or the removal of the package [9], it
isn't meant to store a "raw" command like you did. At first
glance, there's no need for an install script in your case so you
can remove that variable.
- The "source" array is wrong and will fail to download the repo.
It should be "git*+*$url" instead of "git*=*$url". See the VCS
sources section of the wiki for more information [10]. Just for
the sake of it, I'll add the usual trailing ".git" at the end,
like so: source=("git+${url}.git")
- Because the sources are not static in a VCS package, you have
to explicitly skip the checksum by adding 'SKIP' to the "md5sums"
array [11]. Letting it empty will not work.
On a side note, I recommend switching to a more modern and secure
hash algorithm generally speaking ("sha256sums" for instance).
- You shouldn't "git clone" the repo inside the "build()"
function. This is implicitly done beforehand by filling the
correct/proper sources in the "source" array.
- The "ninja -C _build install" part as to be called within the
"package()" function. You'll also need to setup the destination
directory to "$pkgdir" which is the temporary directory where
"makepkg" builds and bundles the package [12]. See the "package()"
section of the Meson packaging guidelines for more information [13].
Overall, I advice you to read closely the three following Arch
wiki pages which should contain most of the information you'll
need to write a proper PKGBUILD for "lemoa-git":
- PKGBUILD [14]
- VCS Packaging Guidelines [15]
- Meson Packaging Guidelines [16]
I hope this helps :)
Don't hesitate to ask for details or further questions if needed!
[1]
https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
[2] https://github.com/lemmygtk/lemoa/blob/main/LICENSE
[3] https://wiki.archlinux.org/title/PKGBUILD#license
[4] https://github.com/lemmygtk/lemoa#build-dependencies
[5] https://archlinux.org/packages/extra/x86_64/gtk4/
[6] https://archlinux.org/packages/core/x86_64/pkgconf/
[7] https://archlinux.org/packages/core/any/base-devel/
[8] https://wiki.archlinux.org/title/PKGBUILD#makedepends
[9]
Re: pkgbuild
Also, the proper mailing list to ask for a PKGBUILD review is
aur-general@lists.archlinux.org.
I haven't noticed you used aur-...@lists.archlinux.org instead when I
replied the first time so I forwarded the discussion to the proper
mailing list this time via this reply.
Let's continue this discussion here please :)
For everyone's context, here's the initial PKGBUILD provided for a review:
https://bpa.st/TXEW2
--
Regards,
Robin Candau / Antiz
Le 02/07/2023 à 20:59, Robin Candau a écrit :
Le 02/07/2023 à 04:20, james smith a écrit :
I am trying to package this https://github.com/lemmygtk/lemoa this is
my pkgbuild any tips on how to improve it before I send it to aur is
appreciated
Hi James,
_/Quick note before reviewing your PKGBUILD:/_
/When asking for a review, try to make your PKGBUILD publicly readable
somewhere (by posting it in paste service for instance, like
https://bpa.st/ or https://gist.github.com/). This is way easier to
track as the discussion progresses and way more "trust worthy" than an
attached file sent to a mailing list. /
In it's current state, your PKGBUILD won't work and needs some
modifications and improvements.
Here's what I can list after a quick review:
- The comments at the top provided by the PKGBUILD example file should
be removed.
- You can remove variables/arrays that are empty/unused in your
PKGBUILD (epoch, groups, checkdepends, etc...).
- Consider filling out the maintainer info at the top of the PKGBUILD.
This isn't mandatory but it is recommended and appreciated.
- The pkgname you chose refers to a VCS package ("lemoa*-git*"). If
you indeed want your package to be a VCS package (meaning that it
relies on the latest upstream commit instead of a specific
tag/release) then you have to adapt your PKGBUILD accordingly with a
proper "pkgver()" function [1].
Otherwise, switch your "pkgname" to "lemoa" and update the rest of the
PKGBUILD accordingly.
- 'GNU' isn't a valid license. The correct license for "lemoa"
currently is 'GPL3' [2]. See also the license section of the PKGBUILD
wiki page for more information [3].
- The 'Gtk' package listed in the "depends" array isn't a valid
package. "Lemoa" seems to depends on GTK-4 [4] which can be installed
via the "gtk4" package in Arch [5].
- Upstream documentation also lists "rust, cargo and pkg-config" as
"Build dependencies" [4]. According to that, you should add the
"cargo" package (which also provides "rust") to your "makedepends" array.
However, you don't have to explicitly list the "pkg-config" package
(provided by the "pkgconf" package in Arch [6]) because it is a member
of the "base-devel" meta-package [7] which is assumed installed during
build-time [8].
- The "install" variable expects the name of an optional ".install"
script used to perform tasks before or after the install, the upgrade
and/or the removal of the package [9], it isn't meant to store a "raw"
command like you did. At first glance, there's no need for an install
script in your case so you can remove that variable.
- The "source" array is wrong and will fail to download the repo. It
should be "git*+*$url" instead of "git*=*$url". See the VCS sources
section of the wiki for more information [10]. Just for the sake of
it, I'll add the usual trailing ".git" at the end, like so:
source=("git+${url}.git")
- Because the sources are not static in a VCS package, you have to
explicitly skip the checksum by adding 'SKIP' to the "md5sums" array
[11]. Letting it empty will not work.
On a side note, I recommend switching to a more modern and secure hash
algorithm generally speaking ("sha256sums" for instance).
- You shouldn't "git clone" the repo inside the "build()" function.
This is implicitly done beforehand by filling the correct/proper
sources in the "source" array.
- The "ninja -C _build install" part as to be called within the
"package()" function. You'll also need to setup the destination
directory to "$pkgdir" which is the temporary directory where
"makepkg" builds and bundles the package [12]. See the "package()"
section of the Meson packaging guidelines for more information [13].
Overall, I advice you to read closely the three following Arch wiki
pages which should contain most of the information you'll need to
write a proper PKGBUILD for "lemoa-git":
- PKGBUILD [14]
- VCS Packaging Guidelines [15]
- Meson Packaging Guidelines [16]
I hope this helps :)
Don't hesitate to ask for details or further questions if needed!
[1]
https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function
[2] https://github.com/lemmygtk/lemoa/blob/main/LICENSE
[3] https://wiki.archlinux.org/title/PKGBUILD#license
[4] https://github.com/lemmygtk/lemoa#build-dependencies
[5] https://archlinux.org/packages/extra/x86_64/gtk4/
[6] https://archlinux.org/packages/core/x86_64/pkgconf/
[7] https://archlinux.org/packages/core/any/base-devel/
[8] https://wiki.archlinux.org/title/PKGBUILD#makedepe
Re: PKGBUILD review.
Fabio,
a newbie question:
> there is validpgpkeys but is not checked in source=()
would that suggest changing
source=("git+https://gitlab.com/minecraftchest1/steamdeck-file-share-tool#tag=$pkgver";)
to something like this
source=("git+https://gitlab.com/minecraftchest1/steamdeck-file-share-tool#tag=$pkgver?signed";)
?
also, are the quotation marks above optional? i.e., could it have been
written
source=(git+https://gitlab.com/minecraftchest1/steamdeck-file-share-tool#tag=$pkgver?signed)
cheers, Greg
Re: PKGBUILD review.
Hi,
Here's how I would have wrote it (see commented changes at the bottom):
# Maintainer: Minecraftchest1
pkgname=file-sharing-tool
pkgver=0.2.0
pkgrel=1
pkgdesc="A tool to help setup file sharing using ssh."
arch=('any')
url=
["https://gitlab.com/minecraftchest1/steamdeck-file-share-tool";](https://gitlab.com/minecraftchest1/steamdeck-file-share-tool)
license=('GPL3')
depends=('openssh' 'zenity')
makedepends=('git')
source=("git+${url}#tag=${pkgver}")
sha256sums=('SKIP')
package() {
cd "${srcdir}"
install -Dm 755 "bin/${pkgname}.sh" "${pkgdir}/usr/bin/${pkgname}"
}
Changes:
- Deleted every empty/not used variables to make the PKGBUILD more readable.
- Deleted 'sed' and 'bash' from the "depends" array. Indeed, they belong to the
"base" group package [1], which contains the set of packages that define a
basic Arch Linux installation. Base group's members don't necessarily have to
be listed as dependencies since you expect people to have them installed anyway.
- Deleted 'coreutils' from the "makedepends" array for the same reason as
above. By the way, the same rules apply for "base devel" metapackage's members
[2], as far as AUR package are concerns [3].
- Added 'git' to "makedepends". Indeed, since you're not relying on a release
archive but rather of a "git cloned" repo in the "source" array, "git" is
needed to download and install your package.
- Populated the use of variables in the "source" array and in the "package"
function instead of re-typing raw metadata (url, package name, source
directory, etc...). Obviously you don't have to, but that's more elegant I
guess.
- Deleted the "validgpgkey" array since it doesn't appear to be used.
- Modified the "install" command in the "package" function to install the
package with proper permissions and with a proper name (without ".sh").
I wrote that on the go, I didn't test the PKGBUILD myself so make sure it works
correctly on your side :)
I would eventually suggest making a release of your package on GitLab so you
could rely on a release's archive in the "source" array instead of "git
cloning" the repo from a specific tag. That would allow you to check the
integrity of the download source instead of skipping it
("sha256sums=('SKIP')"), which is a more trusty in my opinion.
Also, as "Fabio Loli" wrote in his answer, you should eventually add a license
file/indication in the GitLab repo.
I let anyone else add more details/thoughts if needed.
[1] https://archlinux.org/packages/core/any/base/
[2] https://archlinux.org/groups/x86_64/base-devel/
[3] https://wiki.archlinux.org/title/Arch_User_Repository#Prerequisites
Regards,
Antiz (Robin C.)
Le 12/12/2022 à 19:16, Fabio Loli a écrit :
> Il 12/12/22 19:03, Wyatt C Jackson ha scritto:
>
>> I recently put together a PKGBUILD file for a tool I made and want to put on
>> the AUR. While I believe it should be fine, I would like to have it reviewed
>> before I upload it.
>>
>> ---
>> ```
>> # Maintainer: Minecraftchest1
>> pkgname=file-sharing-tool
>> pkgver=0.2.0
>> pkgrel=1
>> epoch=
>> pkgdesc="A tool to help setup file sharing using ssh."
>> arch=('any')
>> url=
>> ["https://gitlab.com/minecraftchest1/steamdeck-file-share-tool";](https://gitlab.com/minecraftchest1/steamdeck-file-share-tool)
>> license=('GPL3')
>> groups=()
>> depends=('openssh' 'zenity' 'sed' 'bash')
>> makedepends=('coreutils')
>> checkdepends=()
>> optdepends=()
>> provides=()
>> conflicts=()
>> replaces=()
>> backup=()
>> options=()
>> install=
>> changelog=
>> source=("git+https://gitlab.com/minecraftchest1/steamdeck-file-share-tool#tag=$pkgver";)
>> noextract=()
>> md5sums=()
>> validpgpkeys=('B136A3601568A8CE2493')
>> sha256sums=('SKIP')
>>
>> package() {
>> cd steamdeck-file-share-tool
>> install -D -v bin/file-sharing-tool.sh -t $pkgdir/usr/bin
>> }
>> ```
>
> Hello,
>
> missing git as makedepends
> makedepends on coreutils not needed
> there is validpgpkeys but is not checked in source=()
> there isn't a license or a license indication in your source repo
> please remove unused fields
> please install the script as file-sharing-tool (without .sh)
--
Regards,
Antiz (Robin C.)
Re: PKGBUILD review.
Hello, > please install the script as file-sharing-tool (without .sh) This is not always needed, it depends on how you want it to be, for example "acme.sh" keeps the .sh due to the naming they wanted. However it is PREFERED to use a shebang to the interpreter needed to run the script on the first line of the file: #!/usr/bin/sh Add the above to the top of the script and you can omit the .sh if you desire, it is not mandatory. > makedepends on coreutils not needed You shouldn't put a massive group of packages into the makedepends, however you should include every individual package needed to build it, this includes git as stated already. You should add bash or sh or whatever you are using for the script, and then add the shebang at the top of the script for it. Hope this helps, Polarian OpenPGP_0x0770E5312238C760.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: PKGBUILD review.
Il 12/12/22 19:03, Wyatt C Jackson ha scritto:
I recently put together a PKGBUILD file for a tool I made and want to put on
the AUR. While I believe it should be fine, I would like to have it reviewed
before I upload it.
---
```
# Maintainer: Minecraftchest1
pkgname=file-sharing-tool
pkgver=0.2.0
pkgrel=1
epoch=
pkgdesc="A tool to help setup file sharing using ssh."
arch=('any')
url="https://gitlab.com/minecraftchest1/steamdeck-file-share-tool";
license=('GPL3')
groups=()
depends=('openssh' 'zenity' 'sed' 'bash')
makedepends=('coreutils')
checkdepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=("git+https://gitlab.com/minecraftchest1/steamdeck-file-share-tool#tag=$pkgver";)
noextract=()
md5sums=()
validpgpkeys=('B136A3601568A8CE2493')
sha256sums=('SKIP')
package() {
cd steamdeck-file-share-tool
install -D -v bin/file-sharing-tool.sh -t $pkgdir/usr/bin
}
```
Hello,
missing git as makedepends
makedepends on coreutils not needed
there is validpgpkeys but is not checked in source=()
there isn't a license or a license indication in your source repo
please remove unused fields
please install the script as file-sharing-tool (without .sh)
Re: PKGBUILD review.
Hello, This looks good to me, however I advice to omit any opinions which you have not defined. Apart from that it looks good, make sure to build and install the package to ensure everything is working fine, follow the following: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot Good luck :) Polarian OpenPGP_0x0770E5312238C760.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: PKGBUILD: on makedepends
Georg, Polarian, and kpcyrd, thanks much! that's what made sense. cheers, Greg
Re: PKGBUILD: on makedepends
On 12/12/22 07:31, Greg Minshall wrote: hi. i am putting together a PKGBUILD. there are certain dependencies required for cutting a release, rolling a version, etc. but, for just downloading the sources and building, these dependencies are not needed. can i leave dependencies *out* of makedepends that are only used for non-mainline build/installation tasks? Yes you can leave them out. In makedepends you only add additional dependencies that are used to build the project. The code of release tooling (and its dependencies) can be safely ignored. Cheers!
Re: PKGBUILD: on makedepends
Hello, A package should only build one version of the codebase, so there is a few tags you can use: on its own normally means the latest STABLE version -beta or -unstable etc can be made for unstable builds, such as prerelease builds. -git is used to build the latest commit in the master branch. Whichever PKGBUILD you are making, you should specify ALL dependencies needed at the different stages, you can specify whether a dependency is needed just to build the package (such as a C compiler if the codebase is in C), and then the packages needed for the program to run, this is what people installing your package must also install as well (pacman calculates the dependencies itself when it installs a package, so the user never needs to worry about the dependencies you name in your MAKEPKG). In any case, ensure you name every dependency needed to build the package and also every dependency needed to run the package, this is all outlined within the arch wiki package on creating an AUR package. Hope this helps, Polarian OpenPGP_0x0770E5312238C760.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: PKGBUILD: on makedepends
simpler: in my PKGBUILD, do i need to list in any of the *depends any package that will *not* be used by makepkg? (motivation: the makefile in my package has uses other than building the package, and for some of *those* uses -- such a rolling a rev, etc. -- *do* need other packages.) cheers, Greg Hi Greg, it is "makedeps" not "maintenancedeps". Just put the stuff there that users need to pull sources and build a package. Your maintenance dependencies are not in scope of this. Best Georg
Re: PKGBUILD: on makedepends
hi, mpan, > Hello. makepkg does not support chosing between different > configurations. One PKGBUILD, one build type. If multiple build > configurations are needed, write (or generate) multiple PKGBUILDs. thanks for the reply. i apologize, my question was very poorly phrased. simpler: in my PKGBUILD, do i need to list in any of the *depends any package that will *not* be used by makepkg? (motivation: the makefile in my package has uses other than building the package, and for some of *those* uses -- such a rolling a rev, etc. -- *do* need other packages.) cheers, Greg
Re: PKGBUILD: on makedepends
hi. i am putting together a PKGBUILD. there are certain dependencies required for cutting a release, rolling a version, etc. but, for just downloading the sources and building, these dependencies are not needed. can i leave dependencies *out* of makedepends that are only used for non-mainline build/installation tasks? Hello. makepkg does not support chosing between different configurations. One PKGBUILD, one build type. If multiple build configurations are needed, write (or generate) multiple PKGBUILDs. OpenPGP_signature Description: OpenPGP digital signature
