I would suggest that the base group belongs in the chroot.
Things are going the other direction, though. The helper scripts (<repo>-<arch>-build) used to install base, but they don't anymore. Things are moving away from assuming base is installed, not toward.
]]>Xyne wrote:Somewhat more seriously, reducing keystrokes is also one of the arguments for omitting deps, as though robustness is not worth typing a few more words.
That seems to be the case ... mostly. The 'mostly' part is what I'm not happy about.
A somewhat related question: I noticed some packages belong to both base and base-devel: file findutils gawk gettext grep gzip pacman sed texinfo util-linux which.
Why is that?
When we made devtools only install base-devel in chroot, we added several base packages to base-devel as they were also commonly used for building packages too.
Several base or base devel packagel depends on base packages because we want to set the order of installation to make them install correctly in an empty chroot. Of course, we try to avoid dependency cycle.
Also, for packages that only depends on base package, I personnally prefer have a dependency on package instead of an empty or removed depends array. This way you don't need to wonder if the empty/missing depends is a mistake or not.
]]>sitquietly wrote:... and I think that the rule should be followed:
(1) The depends array should not list members of the the base group.
And if you do that, a good portion of the packages in the main repos wouldn't build with devtools, which is what is used to build all packages in the repos.....
I see your point. They would build just fine, if we assume that the base group is always present. I think that could work well. I would suggest that the base group belongs in the chroot:
sudo mkarchroot $CHROOT/root base base-devel
but there has been no consensus that I know of on the definition and use of the base group.
]]>... and I think that the rule should be followed:
(1) The depends array should not list members of the the base group.
And if you do that, a good portion of the packages in the main repos wouldn't build with devtools, which is what is used to build all packages in the repos
My understanding of the current situation is that anything in base-devel can be assumed at build time, anything needed by pacman can be assumed at install time, anything needed at run time needs to be included in the depends array. And, of course, anything listed in the depends array can be assumed at both build time and install time.
I don't know if this is official, though.
]]>Correct me if I'm wrong, but ..... The recommendation that such dependencies should not be listed seems a "style" issue, as listing them does no harm.
In my experience it is more than a style issue and I think that the rule should be followed:
(1) The depends array should not list members of the the base group.
(2) The makedepends array should not list members of the base-devel group.
Of course if the package is a member of the base or base-devel groups itself then it had better list the other members of the group that it depends on.
One problem I run into when people don't follow the rules is that when rebuilding Archlinux from source code the dependency graph for a set of upgradable packages is far more likely to have unresolvable cycles in it if it runs too low into the tree (into the base groups). I hate dependency cycles! The rules (no core package may depend on an extra or community package, no non-base package lists base packages as dependencies) let us assume that the "operating system" (base + base-devel) can be updated prior to any pending update in the non-base packages. It is never necessary to update non-base packages first.
Maybe it will help pkgbuild writers to see the lists and try to remember that these packages don't go into the depends/makedepends (of course the list can change).
$ group base
bash
bzip2
coreutils
cronie
cryptsetup
device-mapper
dhcpcd
diffutils
e2fsprogs
file
filesystem
findutils
gawk
gcc-ada
gcc-fortran
gcc-go
gcc-libs
gcc-objc
gettext
glibc
grep
gzip
heirloom-mailx
inetutils
iproute2
iputils
jfsutils
less
licenses
logrotate
lvm2
man-db
man-pages
mdadm
nano
netctl
pacman
pciutils
pcmciautils
perl
ppp
procps-ng
psmisc
reiserfsprogs
sed
shadow
sysfsutils
systemd-sysvcompat
tar
texinfo
usbutils
util-linux
vi
which
xfsprogs
$ group base-devel
autoconf
automake
binutils
bison
fakeroot
file
findutils
flex
gawk
gcc
gettext
grep
groff
gzip
libltdl
libtool
m4
make
pacman
patch
pkg-config
sed
sudo
texinfo
util-linux
which
That's my 2 cents.
]]>Somewhat more seriously, reducing keystrokes is also one of the arguments for omitting deps, as though robustness is not worth typing a few more words.
That seems to be the case ... mostly. The 'mostly' part is what I'm not happy about.
A somewhat related question: I noticed some packages belong to both base and base-devel: file findutils gawk gettext grep gzip pacman sed texinfo util-linux which.
Why is that?
And most importantly: why use tar instead of bsdtar? ;P
It saves some busy maintainers 3 keystrokes.
Somewhat more seriously, reducing keystrokes is also one of the arguments for omitting deps, as though robustness is not worth typing a few more words.
]]>And most importantly: why use tar instead of bsdtar? ;P
]]>I see this just like keeping unsupported packages installed. It is not against any rule for me to keep using grub-0.97, but I know that this was my choice and I am responsible for dealing with any issues that arrive from it. Just the same, no one is *required* to have base and base-devel installed, but if one choses not to have these installed, they should be ready to deal with any resulting issues.
This may be the prevailing stance among the developers, but why then add and keep dependencies from 'base' in the 'depends'?
https://bugs.archlinux.org/task/26318
inetutils won't be added, because it is in the base group, but bash (also in base group) is listed: https://www.archlinux.org/packages/community/any/abcde/
wget was in the base group at that time https://projects.archlinux.org/svntogit … 3d951b5489 too
I don't want to appear trollish, but have a look at https://bugs.archlinux.org/task/25997
$ file /usr/bin/strace
/usr/bin/strace: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=53fc892bf4679b6733df98b8cc27974076531474, stripped
$ file /usr/bin/strace-graph
/usr/bin/strace-graph: Perl script, ASCII text executable
or https://bugs.archlinux.org/task/25782 where perl is an explicit dependency, unlike in https://bugs.archlinux.org/task/25571 case.
]]>I'll leave it there to avoid going too far off topic.
]]>If PkgX depends on perl, though, and perl is not listed, and the user does not have the base group installed, they should be able to figure out and deal with the failed build.
I see this just like keeping unsupported packages installed. It is not against any rule for me to keep using grub-0.97, but I know that this was my choice and I am responsible for dealing with any issues that arrive from it. Just the same, no one is *required* to have base and base-devel installed, but if one choses not to have these installed, they should be ready to deal with any resulting issues.
]]>Do not assume that the base group is installed. Not all users have the full base group and it is neither required nor expected. This is especially true for minimalist chroots.
I already know your stance on this :-)
I can obviously follow your suggestion for the PKGBUILDs I create, but what about the others?
https://bugs.archlinux.org/task/25571
We expect users to have base group installed. Perl is in base group and perl depends on db. Does this mean db should be in base group?
No, as it will be automaticallly installed when the base package which depends on it will be installed. So it doesn't need to be in base group.
I would like to get this straight, if possible, as it could result in long-term reduction of bug reports filled and less grrr all around.
Some reports about adding new dependency are resolved as 'Not a bug' https://bugs.archlinux.org/task/26318 while others (like aforementioned https://bugs.archlinux.org/task/26105 ) are fixed.
def whatdo(foo):
if the package requires foo to run:
add foo to the depends array
else if the package requires foo to build
if foo is in the base-devel group:
do nothing
else:
add foo to the makedepends array
As for whether to include dependencies of other dependencies: I include all direct dependencies for logical consistency. Some don't.
For example, if your package depends on foo and bar, but foo also depends on bar, then some people will only include foo. I think this is incorrect because your package should not break if some other package's dependencies change (e.g. due to a rewrite). The overhead of checking for a few more files is trivial.
p.s. Do not assume that the base group is installed. Not all users have the full base group and it is neither required nor expected. This is especially true for minimalist chroots.
This just increases the workload for pacman during dependency resolution.
I just don't understand why people are concerned by this. Most of the time dependencies can be resolved by a simple directory listing of the local database as the package names and versions are there. The only real issue are providers which requires pacman to read a file for each package. Even then I would say it's simply poor design for not collecting providers when building the local database.
In my opinion, logical completeness is worth a few extra CPU cycles and IO operations. Taking shortcuts in programming that compromise robustness is poor design.
]]>