FS#6465 - makepkg wants findutils

Attached to Project: Arch Linux
Opened by Sergej Pupykin (sergej) - Wednesday, 21 February 2007, 14:58 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 21 February 2007, 16:50 GMT
Task Type Bug Report
Category Packages: Current
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Please add findutils to pacman deps, because of makepkg uses find command.
This task depends upon

This task blocks these from closing
 FS#6316 - Pacman 3 release bugcatcher 
Closed by  Dan McGee (toofishes)
Wednesday, 28 February 2007, 05:58 GMT
Reason for closing:  Not a bug
Additional comments about closing:  http://bugs.archlinux.org/task/6501

See above bug for the new stuff and comments about a 'base' group. Closing this as it is not just a pacman issue.
Comment by Dan McGee (toofishes) - Wednesday, 21 February 2007, 16:55 GMT
Do we include things that are in the base set in depends? Otherwise you get the rediculousness of including gcc, glibc, etc.

Otherwise, we have to at least add bash, findutils, file, grep, gzip, sed, tar, and a download program (wget) from a quick scan of the list. This seems excessive to me.

While on the subject of dependencies, python is more of an optional dependency? If one wants to use the rankmirrors script, they need it, but not for anything else that I can think of.
Comment by Aaron Griffin (phrakture) - Wednesday, 21 February 2007, 16:59 GMT
findutils is in 'base'. Typically it is assumed that all of base is installed. Adding these packages could easilly get out of hand.

Currently, makepkg would depend on:
bash
coreutils
bzip2 (??)
file
findutils
grep
gzip
sed
tar
wget
zlib

Not to mention common utilities used to build most packages:
gcc
m4
make
pkgconfig
patch


Should we also add all these as dependencies? I think not.
Comment by Aaron Griffin (phrakture) - Wednesday, 21 February 2007, 17:00 GMT
I also forgot that the extract functionality can also use the following: cpio and compress
Comment by Sergej Pupykin (sergej) - Wednesday, 21 February 2007, 17:15 GMT
Hm.. May be base metapackage should be made? To ensure that base properly installed with pacman -S base?
Comment by Aaron Griffin (phrakture) - Wednesday, 21 February 2007, 17:22 GMT
Even if a base metapackage were made, that's not a pacman bug. However, it is the opinion of most arch devs that a 'base' package is a bad idea. The reason being that 'base' is installed by default, You are free to remove packages from base if you want, but you *MUST* know what you're doing.
Still we're getting into the realm of global arch policies and away from pacman. Do you still consider this a pacman bug?
Comment by Sergej Pupykin (sergej) - Wednesday, 21 February 2007, 17:39 GMT
I don't consider this as pacman bug since 3rd comment :)
I think this bug can be closed. Thanks for explanation.
Comment by Dan McGee (toofishes) - Wednesday, 21 February 2007, 17:57 GMT
sergej and phrakture- why don't we close this bug, as it is filed as a pacman bug, after another feature request is filed to look into the idea of a base package. Perhaps include some of the comments stated above (especially the 'base' package is a bad idea one).

I'll add my two cents to put in another bug report- I uninstall things like mdadm from my systems after a new install because I know I will never need it. This is in the base package, and yet caters to a small subset of users. I think the concept of a 'base' package should be split from what is included even on the 'base' install CD. Only a few basic packages should be absolutely essential.
Comment by Jens Adam (byte) - Thursday, 22 February 2007, 13:32 GMT
I also tend to kill a lot from "base" afterwards.
Additionally I remove makedepends after successful builds in order to catch hidden depends in the future. I'll agree that this bug could be closed regarding pacman (but a makepkg feature offering to remove makedepends afterwards might be nice though).

I'm currently reading a bit into Debian policy, they have a "build-essential" package, pkgs marked as "essential" or "required", a 'priority' field, and a whole shitload of other stuff we'll hopefully never implement.

Loading...