You are not logged in.
I'm submitting a package to the AUR and the only two packages it depends on are glibc and coreutils. The Arch wiki says (basically) not to include packages that are guaranteed to already be on everyone's system. Since both of those packages are essential packages and part of the base group, do I need to include them in the depends array of the PKGBUILD, or can I just leave it empty?
PS: I apologize if this has been asked before, but I couldn't find anything specific when I searched for this.
Last edited by lb.laboon (2015-02-14 16:57:22)
Offline
https://wiki.archlinux.org/index.php/Ar … requisites
and
https://wiki.archlinux.org/index.php?ti … did=356560
EDIT: using the little tip in the 2nd link shows that both glibc and coreutils end in a 0 exit code meaning they are including in base-devel or pulled in by a dep in base-devel so no need to include them.
Last edited by graysky (2015-02-14 17:01:12)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Right. I saw that, but I didn't know if the same applied to members of the "base" group as well (it only explicitly mentions base-devel). I assumed it did, but I just wanted to be 100% certain.
Thanks for the confirmation.
Last edited by lb.laboon (2015-02-14 17:08:11)
Offline
There's no official policy about including packages from the base group. Some packagers include them, others don't. Personally, I'm in the "include them" camp.
Note that base-devel is only assumed at build time, not at run time.
Offline
Include them. Although an Arch system without glibc has issues...
Offline
There's no official policy about including packages from the base group. Some packagers include them, others don't. Personally, I'm in the "include them" camp.
Note that base-devel is only assumed at build time, not at run time.
Include them. Although an Arch system without glibc has issues...
Ok, based on both of your input and looking at other packages, I think I will include glibc but not coreutils. If I do 'pacman -Qi coreutils' on my system there's only 5 packages that list it as a dependency, as opposed to ~50 that list glibc. Plus, the only reason it needs coreutils is for cp and rm, and a system without those commands probably can't even run a package manager let alone install my package
Thanks!
Offline
What's the package? Are cp and rm only used during the build? If so, don't list anything as they are required by base-devel.
If this is not for building, I'm curious how you would use cp or rm without also requiring a shell. Is this C code using an exec family function to run cp or rm? Or if it is C code and you use system() that requires a shell. Or perahps are /usr/bin/cp and /usr/bin/rm called from a service file? I can't think of other ways they'd be used without also requiring a shell. If a shell is needed, just put `sh` as a dependency as all the POSIX shells provide that. (edit: oops, no they don't it seems. They should).
EDIT: just found it, yup, it looks like coreutils would be needed. (edit again, crossposed with the below).
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
No, they're runtime dependencies, not a build dependency. It's C code which uses fork() and execlp() to call cp and rm.
EDIT: just found it, yup, it looks like coreutils would be needed. (edit again, crossposed with the below).
Ok, I'll include that as well then. Thanks!
Last edited by lb.laboon (2015-02-15 16:30:29)
Offline
You can run a system quite happily without coreutils... Look at busybox.
Offline
You can run a system quite happily without coreutils... Look at busybox.
to be more exactly you can replace the GNU part on GNU/Linux for... well... busybox, zsh, llvm+clang and who know what more.
I think arch need a writted policity on this issue, you know, the "is not writted therefor not obligatory blablablah" argument can raise at some point.
Well, I suppose that this is somekind of signature, no?
Offline
You can run a system quite happily without coreutils... Look at busybox.
And that actually brings up another point...my package doesn't specifically need coreutils, it just needs some implementation of cp and rm, regardless of who provides it.
Ultimately I think I've decided to put glibc in the depends and leave coreutils out, since while it's certainly possible to have a box without coreutils, I don't think I've ever seen a functional *nix OS without cp or rm.
Offline
Of course, another solution would simply be to use the link() and unlink() C functions instead of the cp and rm calls. This would save the forked process and eliminate the dependency.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Of course, another solution would simply be to use the link() and unlink() C functions instead of the cp and rm calls. This would save the forked process and eliminate the dependency.
The purpose of the program is to make backups of directories, so that isn't a viable solution.
Offline