Discussion:
Should "base" packages be listed as dependencies?
(too old to reply)
Baptiste Jonglez
2017-03-22 20:45:13 UTC
Permalink
Hi,

I was pretty confident that "base" packages should be listed as
dependencies in PKGBUILDs, i.e. they are not assumed to be installed (as
opposed to "base-devel" for build dependencies).

This belief is reinforced by the fact that namcap gives dependencies error
about packages such as glibc (which is in "base"):

E: Dependency glibc detected and not included (libraries ['usr/lib/libc.so.6', 'usr/lib/libcrypt.so.1'] needed in files ['usr/lib/libcli.so.1.9.7'])

But I could not find any documentation about this. On the contrary, this
wiki page [1] says the opposite:

In addition, the base group is assumed to be installed on *all* Arch
systems.

Am I missing something obvious?

Thanks,
Baptiste

[1] https://wiki.archlinux.org/index.php/Makepkg#Usage
Lex Black
2017-03-22 20:51:50 UTC
Permalink
Base and base-devel are a requirement for using the AUR and those packages shouldn't be added to the depends.

See the prerequisites on the AUR wiki page.
Bartłomiej Piotrowski
2017-03-22 20:56:57 UTC
Permalink
Post by Lex Black
Base and base-devel are a requirement for using the AUR and those packages shouldn't be added to the depends.
See the prerequisites on the AUR wiki page.
Well, no.

Someone who builds a package is expected to have base-devel installed.
It does not apply to the base group. And worth noting, base-devel does
not include base.

Bartłomiej
Lex Black
2017-03-22 21:31:35 UTC
Permalink
Post by Lex Black
Post by Lex Black
Base and base-devel are a requirement for using the AUR and those
packages shouldn't be added to the depends.
Post by Lex Black
See the prerequisites on the AUR wiki page.
Well, no.
Someone who builds a package is expected to have base-devel installed.
It does not apply to the base group. And worth noting, base-devel does
not include base.
Bartłomiej
Ah, kinda on the wrong way. Dunno why I was thinking base-devel would include base.
Thanks for the correction
Tinu Weber
2017-03-22 21:06:41 UTC
Permalink
Post by Lex Black
Base and base-devel are a requirement for using the AUR and those
packages shouldn't be added to the depends.
See the prerequisites on the AUR wiki page.
The policy is only about base-devel; for base, there does not appear to
be a clear policy.

I personally always put those packages in the dependency list, because I
consider the choice of packages in base to be extremely arbitrary. But
some TUs and devs apparently do not do that, which is probably why there
is this "troubleshooting" part in [2], where they recommend installing
*all* of base.

[1] https://wiki.archlinux.org/index.php/Arch_User_Repository#Foo_in_the_AUR_does_not_compile_when_I_run_makepkg.3B_what_should_I_do.3F
Doug Newgard
2017-03-22 21:12:51 UTC
Permalink
On Wed, 22 Mar 2017 21:45:13 +0100
Post by Baptiste Jonglez
Am I missing something obvious?
Thanks,
Baptiste
There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.
NicoHood
2017-03-22 21:36:48 UTC
Permalink
Post by Doug Newgard
On Wed, 22 Mar 2017 21:45:13 +0100
Post by Baptiste Jonglez
Am I missing something obvious?
Thanks,
Baptiste
There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.
You need to include base packages which are not in base-devel, as the
package won't build without those sometimes. For example some packages
detect systemd at build time and then adds its service files to the
package. At least as makedepends they need to be specified.

I was also angry about this first, but this is actually a more clear way
to build packages without unnecessary dependencies. Every user should
build packages using devtools anyways to detect deps properly and to
produce clean packages.

~Nico
Eli Schwartz via aur-general
2017-03-22 23:17:17 UTC
Permalink
Post by NicoHood
Post by Doug Newgard
On Wed, 22 Mar 2017 21:45:13 +0100
Post by Baptiste Jonglez
Am I missing something obvious?
Thanks,
Baptiste
There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.
You need to include base packages which are not in base-devel, as the
package won't build without those sometimes. For example some packages
detect systemd at build time and then adds its service files to the
package. At least as makedepends they need to be specified.
I was also angry about this first, but this is actually a more clear way
to build packages without unnecessary dependencies. Every user should
build packages using devtools anyways to detect deps properly and to
produce clean packages.
makedepends, maybe.

Arch Linux does not support people who don't have systemd installed
though, and regarding Baptiste's initial example of glibc, if you don't
have glibc installed then your system is so screwed up it's not even
funny...

Given that the official instructions for installing Arch boils down to
"install the base group into a blank partition and arrange a bootloader
to boot that base group", I feel it is eminently reasonable to assume
all valid Arch Linux systems have the base group installed... especially
because some repo packages *are* built with implicit dependencies
because of that exact logic. You really can't just go around
uninstalling parts of base, or rather you can, but then it is up to you
to know when your unsupported actions are likely to break something.
(I say this with the full knowledge that I myself uninstall certain
things I don't feel belong in base at all. I am willing to debug my own
self-inflicted problems...)

Though thinking about this, I actually wonder, maybe devtools should
instruct you (rhet.) to install both base and base-devel into a build
chroot...

...

@Baptiste,

The fact that namcap emits a warning, doesn't actually mean anything. :)
namcap says/doesn't say a lot of things that are wrong, and all that
*this* means is that namcap doesn't explicitly include code to filter
out warnings for base packages. That could be because a) the namcap
maintainer felt they should be dependencies anyway, or b) no one thought
of it/decided to implement a filter, or c) both.
namcap being what it is, I am 99.999999999999% sure it is either b or c.
--
Eli Schwartz
beest
2017-03-23 01:07:39 UTC
Permalink
Post by Eli Schwartz via aur-general
Arch Linux does not support people who don't have systemd installed
though, and regarding Baptiste's initial example of glibc, if you don't
have glibc installed then your system is so screwed up it's not even
funny...
Given that the official instructions for installing Arch boils down to
"install the base group into a blank partition and arrange a bootloader
to boot that base group", I feel it is eminently reasonable to assume
all valid Arch Linux systems have the base group installed... especially
because some repo packages *are* built with implicit dependencies
because of that exact logic. You really can't just go around
uninstalling parts of base, or rather you can, but then it is up to you
to know when your unsupported actions are likely to break something.
(I say this with the full knowledge that I myself uninstall certain
things I don't feel belong in base at all. I am willing to debug my own
self-inflicted problems...)
Though thinking about this, I actually wonder, maybe devtools should
instruct you (rhet.) to install both base and base-devel into a build
chroot...
Also xorg-server is generally implicit for anything requiring X
(optionally or otherwise), but that's also not really codified anywhere.
The only guidance anyone is given is that only base-devel is assumed to
be installed for makedepends, but in practice that's hardly the sole
circumstance.

I'm also on the side of explicitly assuming that base is installed (and
having the wiki and PKGBUILD dox reflect as much), but before that there
should possibly be a discussion about what actually belongs in base in
the first place. A few folks are of the mind that a good chunk of the
group is wholly unnecessary and should be culled.
Eli Schwartz via aur-general
2017-03-23 02:31:34 UTC
Permalink
Post by beest
I'm also on the side of explicitly assuming that base is installed (and
having the wiki and PKGBUILD dox reflect as much), but before that there
should possibly be a discussion about what actually belongs in base in
the first place. A few folks are of the mind that a good chunk of the
group is wholly unnecessary and should be culled.
I will absolutely agree that there are additional packages in base that
shouldn't be. I have brought this point up before a couple times....
Unfortunately, the maintainers of those packages seem to be entirely
happy to leave them as-is, maybe on the assumption borne out in this
thread that no one cares what is in base (except for silly things like
the Installation Guide which no one cares about either, of course).

Bizarrely, other package groups seem to have clearly-defined meanings
which is strongly against the precedent set by the current base group...

fsck/mkfs support for nonstandard filesystems
- xfsprogs
- reiserfsprogs
- jfsutils

Heavily discouraged by pretty much everyone, why on earth would it match
any conceivable definition of "base"...
- netctl :(

Needed for device encryption/LVM/RAID, which not everyone uses
- cryptsetup
- lvm2
- device-mapper
- mdadm

No firm reason for including
- s-nail (an inert mass unless you go out of your way to configure it)
- nano (vi is the standard, and *I* don't even want to include that
because vim)


I would love for all these to be dropped from base, as I consider them
neither recommended (Scimmia's concept of base IIRC) nor critical (the
intuitive concept of base).

Well, maybe the LVM/encryption stuff could be said to be recommended.
But not critical.
--
Eli Schwartz
Ralf Mardorf
2017-03-23 07:30:34 UTC
Permalink
Post by Eli Schwartz via aur-general
nano (vi is the standard, and *I* don't even want to include that
because vim)
For modern Linux distros nano has become a standard as well. What's bad
with providing it by base? Linux isn't UNIX from the 70s. I'm not using
reiser, but what is so problematic with including reiserfsprogs? It at
least was a Linux FS preferred as default FS for e.g. Suse a few
years back? It's idiotic to discuss such trivialities. Some prefer it
more old school others less old school. You are more old school but
that's not enough, you even want to discuss what belongs to the old
school.

Regards,
Ralf
Eli Schwartz via aur-general
2017-03-23 13:33:02 UTC
Permalink
Post by Ralf Mardorf
Post by Eli Schwartz via aur-general
nano (vi is the standard, and *I* don't even want to include that
because vim)
For modern Linux distros nano has become a standard as well. What's bad
with providing it by base? Linux isn't UNIX from the 70s. Also, I'm not using
reiser, but what is so problematic with including reiserfsprogs? It at
least was a Linux FS preferred as default FS for e.g. Suse a few
years back? It's idiotic to discuss such trivialities. Some prefer it
more old school others less old school. You are more old school but
that's not enough, you even want to discuss what belongs to the old
school.
Because you are either an idiot or being deliberately unhelpful?

You may not have realized, but the post you are replying to was arguing
for a defined minimally bootable runnable operating system. What Suse
used as a default FS is so completely irrelevant you should win an award...

Also, stop discriminating against emacs and Atom, which by the same
logic also belong in base because "stop being so old school".



(I really didn't realize that there was *anyone* who considered the
objectively horrible nano a standard. Almost any other editor ever,
aside from MS Notepad, is better in every respect.... Did anyone else
ever hear of this?)
--
Eli Schwartz
Ralf Mardorf
2017-03-23 17:21:52 UTC
Permalink
Post by Eli Schwartz via aur-general
Post by Ralf Mardorf
Post by Eli Schwartz via aur-general
nano (vi is the standard, and *I* don't even want to include that
because vim)
For modern Linux distros nano has become a standard as well. What's
bad with providing it by base? Linux isn't UNIX from the 70s. Also,
I'm not using reiser, but what is so problematic with including
reiserfsprogs? It at least was a Linux FS preferred as default FS
for e.g. Suse a few years back? It's idiotic to discuss such
trivialities. Some prefer it more old school others less old school.
You are more old school but that's not enough, you even want to
discuss what belongs to the old school.
Because you are either an idiot or being deliberately unhelpful?
You may not have realized, but the post you are replying to was arguing
for a defined minimally bootable runnable operating system. What Suse
used as a default FS is so completely irrelevant you should win an award...
Also, stop discriminating against emacs and Atom, which by the same
logic also belong in base because "stop being so old school".
(I really didn't realize that there was *anyone* who considered the
objectively horrible nano a standard. Almost any other editor ever,
aside from MS Notepad, is better in every respect.... Did anyone else
ever hear of this?)
It's not a standard, don't be that childish and polemic. You are able
to understand what I tried to say in the context of my mail and this
discussion. You insult nearly everybody who posts something to this list
and arch general. You nearly always belittle others. Nano has become
"sort of" a standard, a very common editor, for very good reasons.
Seemingly this is also the reason that nano is part of "base". Your tone
of voice is shameful. There's nothing wrong if "base" includes tools
that are required for several file systems, even if you dislike those
file systems. Nano doesn't come with a GUI and is easy to use,
self-explaining and good enough to edit a config. Vi(m) is complex, not
that easy to use. However, this becomes off-topic and you are anyway
well aware of the facts, you just like to provoke.

I am sorry for you!
Xyne
2017-03-23 03:24:50 UTC
Permalink
On 2017-03-22 19:17 -0400
Post by Eli Schwartz via aur-general
Given that the official instructions for installing Arch boils down to
"install the base group into a blank partition and arrange a bootloader
to boot that base group", I feel it is eminently reasonable to assume
all valid Arch Linux systems have the base group installed... especially
because some repo packages *are* built with implicit dependencies
because of that exact logic. You really can't just go around
uninstalling parts of base, or rather you can, but then it is up to you
to know when your unsupported actions are likely to break something.
(I say this with the full knowledge that I myself uninstall certain
things I don't feel belong in base at all. I am willing to debug my own
self-inflicted problems...)
Though thinking about this, I actually wonder, maybe devtools should
instruct you (rhet.) to install both base and base-devel into a build
chroot...
On 2017-03-22 21:07 -0400
Post by Eli Schwartz via aur-general
I'm also on the side of explicitly assuming that base is installed (and
having the wiki and PKGBUILD dox reflect as much), but before that there
should possibly be a discussion about what actually belongs in base in
the first place. A few folks are of the mind that a good chunk of the
group is wholly unnecessary and should be culled.
The PKGBUILD should specify all necessary information for full dependency
resolution without assuming anything other than base-devel*. Extending the
assumption to the full base group just so some packagers can avoid typing a
few extra words *once* when they create the PKGBUILD is just laziness. It's not
even a real burden given that most deps are pulled in indirectly by other
deps so at most you usually only need to list a few. If a PKGBUILD does not
contain all information for full dependency resolution (minus base-devel), then
it is technically incorrect (it lacks required metadata).

There is no "base installation" of Arch Linux. That's one of the defining
features of this distro. Forcing some people to install bloat and cruft (or
play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
wrong. It also fails to consider use cases such as minimalist chroots for
building packages.


Regards,
Xyne

* I could even argue that makepkg should check for base-devel and include it in
dependency resolution automatically with the --syncdeps option.
Eli Schwartz via aur-general
2017-03-23 03:31:21 UTC
Permalink
Post by Xyne
The PKGBUILD should specify all necessary information for full dependency
resolution without assuming anything other than base-devel*. Extending the
assumption to the full base group just so some packagers can avoid typing a
few extra words *once* when they create the PKGBUILD is just laziness. It's not
even a real burden given that most deps are pulled in indirectly by other
deps so at most you usually only need to list a few. If a PKGBUILD does not
contain all information for full dependency resolution (minus base-devel), then
it is technically incorrect (it lacks required metadata).
Well, it also means, for example, that you don't have to keep listing
things like bash and glibc in literally hundreds of PKGBUILDs.
Post by Xyne
There is no "base installation" of Arch Linux. That's one of the defining
features of this distro. Forcing some people to install bloat and cruft (or
play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
wrong.
There absolutely is a base installation. Unless you are suggesting e.g.
systemd-less systems constitute a supported Arch Linux installation?
Post by Xyne
It also fails to consider use cases such as minimalist chroots for
building packages.
I thought that was the point of suggesting that minimalist build chroots
potentially require base as well...

But hey, I am also perfectly happy listing them only as makedepends. :)
--
Eli Schwartz
Xyne
2017-03-23 06:29:56 UTC
Permalink
Post by Eli Schwartz via aur-general
Well, it also means, for example, that you don't have to keep listing
things like bash and glibc in literally hundreds of PKGBUILDs.
I understand that argument, but it is framed as if people are writing hundreds
of PKGBUILDs at once and the added deps are overly tedious to include, when in
fact they are written one at a time and it's only a few extra words (at most)
alongside however many constitute the PKGBUILD. For makedeps, most of these are
not even needed because they are indirect deps of base-devel. All runtime deps
should be resolved though, either directly or indirectly.

The only valid technical argument would be if the overhead of the dependency
checks is prohibitive. I expect that it is negligible (but admittedly haven't
checked) and it is worth technical correctness.

It's like quoting path variables in PKGBUILDs: most people build in "sane"
paths but it's still poor form to omit the quotes and assume that no one builds
on paths with spaces. The arguments "but I don't want to type more quotes" and
"but all those quotes across all the PKGBUILDs take so many bytes" are rightly
rejected.
Post by Eli Schwartz via aur-general
Post by Xyne
There is no "base installation" of Arch Linux. That's one of the defining
features of this distro. Forcing some people to install bloat and cruft (or
play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
wrong.
There absolutely is a base installation. Unless you are suggesting e.g.
systemd-less systems constitute a supported Arch Linux installation?
This isn't about what is officially "supported". This is about how one tool
performs a task. Arch provides flexibility. There are custom kernels and
alternative init systems in the AUR for example. If you customize your system
then you are expected to deal with problems arising from that customization
yourself, but core functionality of the package manager should not rely on all
users installing essentially the same base system. We are talking about
dependency resolution here. Pacman is not tied to systemd or whatever else you
consider to be part of a "base installation". It shouldn't even matter what
other packages the user is using as long as pacman's own deps are satisfied.
For dependency resolution, Pacman's job is to determine what the user wants to
install and then figure out what else the user needs to install it. All it
needs to do that is the correct metadata, which is just a few extra words in
some text files. That is better than implicit assumptions that may silently
change in the future.
Post by Eli Schwartz via aur-general
I thought that was the point of suggesting that minimalist build chroots
potentially require base as well...
A chroot that requires all of the base group is not minimal, it's bloated.


It's like a lazy fruit vendor dumping apples, oranges, bananas, etc. into one
giant bin because he can't be bothered to put them in separate bins (even
though he has them, and it would be simple to do), then forcing customers who
only want apples to buy big boxes of mixed fruit so that they can sort out the
apples themselves and throw the rest of the fruit away (after paying for it).


Regards,
Xyne
Eli Schwartz via aur-general
2017-03-23 13:32:13 UTC
Permalink
Post by Xyne
Post by Eli Schwartz via aur-general
Well, it also means, for example, that you don't have to keep listing
things like bash and glibc in literally hundreds of PKGBUILDs.
I understand that argument, but it is framed as if people are writing hundreds
of PKGBUILDs at once and the added deps are overly tedious to include, when in
fact they are written one at a time and it's only a few extra words (at most)
alongside however many constitute the PKGBUILD. For makedeps, most of these are
not even needed because they are indirect deps of base-devel. All runtime deps
should be resolved though, either directly or indirectly.
The only valid technical argument would be if the overhead of the dependency
checks is prohibitive. I expect that it is negligible (but admittedly haven't
checked) and it is worth technical correctness.
It's like quoting path variables in PKGBUILDs: most people build in "sane"
paths but it's still poor form to omit the quotes and assume that no one builds
on paths with spaces. The arguments "but I don't want to type more quotes" and
"but all those quotes across all the PKGBUILDs take so many bytes" are rightly
rejected.
It is not poor form, it is outright wrong.

BECAUSE PATHS WITH SPACES ARE A VALID USE-CASE! The only reason I don't
feel comfortable using such build paths purely to show it can be done...
is because AUR maintainers are by and large idiots who upload
irresponsible garbage that breaks all the time and has missing
dependencies of *all* sorts, among other numerous common problems when
sifting through huge mounds of absolutely anything authored by
absolutely anyone. :p

And a system that does not have glibc installed is not a valid use-case.
A system without bash is not a valid use-case. A system without systemd
is not a valid use-case, regardless of how many completely-unsupported
people kludge it together with AUR packages (which also are unsupported).

I don't have actual numbers for the dependency checking time... but it
is surely nonzero, and I see no reason to go out of my way to add them
purely for the sake of slowing down pacman's depchecks to whatever
degree, adding PKGBUILD code churn and decreasing clarity by cluttering
it with obvious no-brainers, given that the result is still lacking in
technical correctness, since *technically*, a binary that only links to
glibc still needs a lot of other stuff like a working system running a
linux kernel to run.

Redefining dependencies as shared library linkages would make this a
more compelling argument.

...

Really, if you want technical correctness, then I expect to be able to
pacstrap any single package into an empty partition/directory and have
pacman resolve dependencies to a sufficient degree to result in a
bootable/chrootable minimal installation in which that package functions
as expected.
Post by Xyne
Post by Eli Schwartz via aur-general
Post by Xyne
There is no "base installation" of Arch Linux. That's one of the defining
features of this distro. Forcing some people to install bloat and cruft (or
play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
wrong.
There absolutely is a base installation. Unless you are suggesting e.g.
systemd-less systems constitute a supported Arch Linux installation?
This isn't about what is officially "supported". This is about how one tool
performs a task. Arch provides flexibility. There are custom kernels and
alternative init systems in the AUR for example. If you customize your system
then you are expected to deal with problems arising from that customization
yourself, but core functionality of the package manager should not rely on all
users installing essentially the same base system.
No, just core functionality of, you know the system. Which explicitly
refuses to support the alternative init systems, with undertones of
such-AUR-packages-may-be-crazy. Arch happily compiles runtime
dependencies of systemd into everything, serenely unconcerned about the
trouble this causes the poor saps who try purging systemd.

Arch is *not* about choice or flexibility, not when it comes to the base
system itself. This is a rather emphatic aspect of the Arch Way. After
several complaints from users about systemd specifically, this *had* to
be emphatically clarified.
Post by Xyne
We are talking about
dependency resolution here. Pacman is not tied to systemd or whatever else you
consider to be part of a "base installation". It shouldn't even matter what
other packages the user is using as long as pacman's own deps are satisfied.
For dependency resolution, Pacman's job is to determine what the user wants to
install and then figure out what else the user needs to install it. All it
needs to do that is the correct metadata, which is just a few extra words in
some text files. That is better than implicit assumptions that may silently
change in the future.
Right... I never suggested that pacman itself enforce a base
installation and I have no idea how you think I would go about doing
that anyway.

People using pacman as a package manager for, say, LFS or MSYS2 are more
than free to provide whatever installation instructions they want, and
make whatever implicit assumptions they like regarding a base
installation, and declare a PKGBUILD style policy suiting those assumptions.

Arch Linux is allowed to have different assumptions than pacman and
makepkg (and base-devel is an example of that).
Post by Xyne
Post by Eli Schwartz via aur-general
I thought that was the point of suggesting that minimalist build chroots
potentially require base as well...
A chroot that requires all of the base group is not minimal, it's bloated.
It's like a lazy fruit vendor dumping apples, oranges, bananas, etc. into one
giant bin because he can't be bothered to put them in separate bins (even
though he has them, and it would be simple to do), then forcing customers who
only want apples to buy big boxes of mixed fruit so that they can sort out the
apples themselves and throw the rest of the fruit away (after paying for it).
The same logic applies to base-devel, most of which will not be used in
any given build. In fact, there are plenty of PKGBUILDs which use
nothing other than a package() function with calls to mkdir/cp/install.

TIL, Arch Linux is bloated and lazy. o_O
--
Eli Schwartz
Xyne
2017-03-25 06:47:07 UTC
Permalink
On 2017-03-23 09:32 -0400
Post by Eli Schwartz via aur-general
And a system that does not have glibc installed is not a valid use-case.
A system without bash is not a valid use-case. A system without systemd
is not a valid use-case, regardless of how many completely-unsupported
people kludge it together with AUR packages (which also are unsupported).
Obviously there has to be a system for a package to be installed on and that
system has a finite number of necessary components that will always be present.
If that's what the base group was, then we would likely be in agreement. As it
stands now, a python module, for example, doesn't need nano, systemd, lvm, tar,
vi, etc.

As for valid use-cases, minimal chroots are one. I'm not going to argue for the
others.
Post by Eli Schwartz via aur-general
I don't have actual numbers for the dependency checking time... but it
is surely nonzero, and I see no reason to go out of my way to add them
purely for the sake of slowing down pacman's depchecks to whatever
degree, adding PKGBUILD code churn and decreasing clarity by cluttering
it with obvious no-brainers, given that the result is still lacking in
technical correctness, since *technically*, a binary that only links to
glibc still needs a lot of other stuff like a working system running a
linux kernel to run.
glibc seems to be your go-to example but it's not the best example. Loads of
packages depend on it already. Should all of those deps be removed? Should you
really be able to uninstall glibc without pacman complaining about broken deps?

A binary that links against glibc should directly depend on it imo. A bash
script should depend only on bash. Same for other scripts and their respective
interpreters.

The remarks about a working system are conflating two distinct concepts. A
system is needed to run code in the first place. That's a given. Once you get
that code running, it in turn directly runs other code or uses other data.
That is a dependency in the sense of package management. The infrastructure for
running the code is not. That's a meta-dependency. If you want to compare the
two, you may as well throw in hardware specs. Those are also equally necessary
but it's a different type of dependency.
Post by Eli Schwartz via aur-general
Redefining dependencies as shared library linkages would make this a
more compelling argument.
Agreed.
Post by Eli Schwartz via aur-general
Really, if you want technical correctness, then I expect to be able to
pacstrap any single package into an empty partition/directory and have
pacman resolve dependencies to a sufficient degree to result in a
bootable/chrootable minimal installation in which that package functions
as expected.
Pacstrap *should* install everything necessary for a chrootable system (minus
whatever mountbinds the host system has do provide). A bootable system is a
different matter. In the chroot case, you want to run foo (foo is the primary
target). In the bootable case, you want to boot a system, and then run foo (so
the system is the primary target).
Post by Eli Schwartz via aur-general
Arch is *not* about choice or flexibility, not when it comes to the base
system itself. This is a rather emphatic aspect of the Arch Way. After
several complaints from users about systemd specifically, this *had* to
be emphatically clarified.
The default installation is a minimal base system, configured by the user to only add what is purposely required.
It is still up to the user to decide which packages to install even if base is
recommended. If you don't use nano or lvm, there is no need to install those
packages, for example. Getting rid of systemd is far more complex due to its
centrality in the package ecosystem, but there are nevertheless plenty of
packages that happily run without systemd and thus systemd is not a direct
dependency.
Post by Eli Schwartz via aur-general
Right... I never suggested that pacman itself enforce a base
installation and I have no idea how you think I would go about doing
that anyway.
The whole discussion is about whether or not the base group should be installed
by default or at least assumed to be installed. If packages will not work
because dependency resolution fails in the absence of unspecified base
packages, then you are essentially forcing the user to install the full base
group (or manually resolve deps after noticing that a package doesn't work).
Post by Eli Schwartz via aur-general
People using pacman as a package manager for, say, LFS or MSYS2 are more
than free to provide whatever installation instructions they want, and
make whatever implicit assumptions they like regarding a base
installation, and declare a PKGBUILD style policy suiting those assumptions.
Arch Linux is allowed to have different assumptions than pacman and
makepkg (and base-devel is an example of that).
Sure. Pacman could assume that the full base group is installed. It could
even assume that all of core is installed. It doesn't need to assume that
though. I think it's better if it makes no assumptions as we can easily provide
the information explicitly.

If you can identify a minimal group of packages that are required for any given
package to run in all use cases, then that would be a reasonable assumption
that could be omitted from explicit deps.
Post by Eli Schwartz via aur-general
The same logic applies to base-devel, most of which will not be used in
any given build. In fact, there are plenty of PKGBUILDs which use
nothing other than a package() function with calls to mkdir/cp/install.
Yep. I think makedeps should be explicit too and I stated so in a previous
reply. I'm not arguing for that here though. Also, base-devel is a little
different in that it is assumed for building packages, not running them. You
don't need to keep it on your system to ensure dependency resolution when
installing packages.
Post by Eli Schwartz via aur-general
TIL, Arch Linux is bloated and lazy. o_O
If you require users to install packages that they will never use and
technically don't require in order to be able to use the system normally, then
that is bloat. If you do so because you don't want to type a few extra words,
then that is indeed lazy.

No need for sarcasm btw.
Ralf Mardorf
2017-03-25 08:19:43 UTC
Permalink
A bash script should depend only on bash.
Hi Xyne,

Seems to be better it would depend on coreutilsor do you asume a bash
script only depends on bash intern commands and woun't use external
commands such as e.g. basename?

[***@archlinux ~]$ pacman -Qo /usr/bin/basename
/usr/bin/basename is owned by coreutils 8.26-1
[***@archlinux ~]$ pactree -r coreutils | grep bash
[***@archlinux ~]$ pactree coreutils | grep bash
│ └─bash provides sh
│ └─bash provides sh
│ └─bash provides sh
It is still up to the user to decide which packages to install even if
base is recommended. If you don't use nano or lvm, there is no need to
install those packages, for example.
A user always is allowed to customize the install. On my install are
even some hard dependencies missing, but on another software level,
not on the base level. The Arch community needs to share some base
system. If we wouldn't, we wouldn't need Arch related mailing lists.
There must be something in common to call Arch "Arch".
The whole discussion is about whether or not the base group should be
installed by default or at least assumed to be installed. If packages
will not work because dependency resolution fails in the absence of
unspecified base packages, then you are essentially forcing the user
to install the full base group (or manually resolve deps after
noticing that a package doesn't work).
Correct. What's wrong with this approach?
You safely could remove nano, to free the immens amount of disc space
it takes. Others, e.g. Eli seemingly do this. Unlikely a package
explicitly will have a hard dependency on nano.

[***@archlinux ~]$ pactree -r nano
nano

Just in case a package really should depend on nano, then the user
needs to reinstall it. I expect a user who decides to remove packages
from "base" to understand what she's doing. There are valid reasons
that base does include a few packages, such as nano, even if those are
not necessarily required or fit to UNIX standards from the 70s.
If you require users to install packages that they will never use and
technically don't require in order to be able to use the system
normally, then that is bloat. If you do so because you don't want to
type a few extra words, then that is indeed lazy.
That's not the point. As already pointed out, the Arch community needs
to have something in common. We could customise Arch Linux a lot, but
if e.g. everybody of us would use a different init system, we wouldn't
share the same distro anymore and can't help each other.

And again, it makes sense that Arch provides software that is _quasi_ a
sort of a standard by base, e.g. nano. OTOH if somebody really
dislikes something like nano that much, a user easily + safely could
remove it. OTOH removing coreutils or systemd-sysvcompat (even if you
don't need sysvinit backward compatibility) wouldn't be very smart.

Assuming that an Arch install is build upon a set of basic packages,
e.g. systemd-sysvcompat is a good approach, not to reduce typing
PKGBUILD dependencies, but to ensure that different Arch Linux installs
have something in common.

Regards,
Ralf
Tinu Weber
2017-03-25 15:31:41 UTC
Permalink
Post by Ralf Mardorf
A bash script should depend only on bash.
Hi Xyne,
Seems to be better it would depend on coreutilsor do you asume a bash
script only depends on bash intern commands and woun't use external
commands such as e.g. basename?
In such a case, yes, the application should state that it depends on
coreutils. I don't see an issue, though, other than "I don't want to
type that".
Post by Ralf Mardorf
It is still up to the user to decide which packages to install even if
base is recommended. If you don't use nano or lvm, there is no need to
install those packages, for example.
A user always is allowed to customize the install. On my install are
even some hard dependencies missing, but on another software level,
not on the base level. The Arch community needs to share some base
system. If we wouldn't, we wouldn't need Arch related mailing lists.
There must be something in common to call Arch "Arch".
I don't think that the Arch community or the OS itself is solely defined
by an arbitrarily selected set of packages that are expected to be
installed. After all, the systems still share the package manager and
the origin of the packages (created and provided by Arch devs) + the
general idea of KISS (e.g. upstream as unpatched as possible, no partial
upgrade support, ...)

I think some people are mixing up these two things:

1. Packages that are expected to be there to guarantee a minimally
working system in most situations.
2. Packages that are expected to be there to provide a minimally
comfortable working environment to the user.

I could live with the group 1 being mandatory (I wouldn't be happy, but
I could accept it). But not group 2, because at that point, things get a
little more subjective. Let me quote the Arch Wiki article on Arch
Post by Ralf Mardorf
Arch Linux is a general-purpose distribution. Upon installation, only
a command-line environment is provided: rather than tearing out
unneeded and unwanted packages, the user is offered the ability to
build a custom system by choosing among thousands of high-quality
packages provided in the official repositories for the x86-64
architecture.
I'm sorry, but I currently find myself "tearing out unneeded and
unwanted packages". And in a sort of a "killing spree", I find myself
removing packages from both groups 1 and 2 as defined above. I end up
with something like my personal little VPS, for instance:

* I won't plug in any USB devices or PCMCIA cards (usbutils,
pcmciautils)
* I use systemd-networkd for my static network configuration (netctl,
dhcpcd)
* I don't use LVM or block-level encryption (lvm2, cryptsetup)
* Being on a VPS, I don't care about RAID (mdadm)
* I don't intend to interact with any other file systems than ext4
(jfsutils, reiserfsprogs, xfsprogs)
* I don't use nano (nano)
* I use zsh as my interactive shell, and generally write my shell
scripts in POSIX sh, for which I have dash installed (and linked sh
to), so bash is installed --asdeps.
* I don't use any of the tools in ineutils, so it's installed --asdeps.
* I still keep the "normal" Linux kernel around "just in case" - but
really I am booting the LTS kernel.

Now, is that no longer Arch Linux? I would say Yes. But with the current
policy, it appears that No. Not because I'm running unsupported
software, but because I just got rid of a few things that I don't need.
Same goes for my laptop setup (although for a smaller set of missing
packages there). Or my little test container, where I don't need the
kernel, for instance.

I do not oppose the idea of having a group of packages that are
*recommended* to be installed - people who don't quite know what they
need can just install that group and assume that they will probably not
run into too much trouble. But people shouldn't be *forced* to install
those packages (or find themselves in the "not supported here!" zone).
Post by Ralf Mardorf
The whole discussion is about whether or not the base group should be
installed by default or at least assumed to be installed. If packages
will not work because dependency resolution fails in the absence of
unspecified base packages, then you are essentially forcing the user
to install the full base group (or manually resolve deps after
noticing that a package doesn't work).
Correct. What's wrong with this approach?
You safely could remove nano, to free the immens amount of disc space
it takes. Others, e.g. Eli seemingly do this. Unlikely a package
explicitly will have a hard dependency on nano.
nano
I find a little irony in the fact that you use to pactree/pacman to show
that nothing depends on nano, when the issue here is exactly that
pactree/pacman becomes unreliable for packages in base.
Post by Ralf Mardorf
Just in case a package really should depend on nano, then the user
needs to reinstall it. I expect a user who decides to remove packages
from "base" to understand what she's doing. There are valid reasons
that base does include a few packages, such as nano, even if those are
not necessarily required or fit to UNIX standards from the 70s.
Yes, those are valid assumptions for a "base install" as in "before the
user starts configuring their system to their needs". And I'm happy that
there is at least one text editor in that "base install". But once I'm
done and have switched to vim or emacs or atom or whatever else I happen
to use, I might feel different about that.

(Just to clarify, I don't get all this hate on nano. It's a fine editor
for people who just want to quickly edit something from a non-graphical
environment and don't want to be bothered learning the quirks of vi or
emacs.)

Of course, nano is tiny, and there is no harm in keeping it around. But
together with all the other packages we don't need, it starts feeling
like clutter. Especially if I have to mentally filter out those packages
from the output of `checkupdates` before I decide whether I want to run
that update, or leave it because it only affects packages I don't use.

Best,
Tinu
Ralf Mardorf
2017-03-25 17:35:44 UTC
Permalink
Post by Tinu Weber
Now, is that no longer Arch Linux? I would say Yes. But with the current
policy, it appears that No. Not because I'm running unsupported
software, but because I just got rid of a few things that I don't need.
Same goes for my laptop setup (although for a smaller set of missing
packages there). Or my little test container, where I don't need the
kernel, for instance.
Some of the mentioned packages you don't need, are packages I don't need, too.
IMO something like "linux" and "dhcpd" are for very good reasons part of " base". Fortunately I'm using "dhcpd", but Instead of "linux" I build my own RT patched kernels.
So I would welcome, if linux-headers would be part of "base" as well. "linux-headers" are dependency of "virtualbox". Wouldn't it be good, if we simply could remove "linux-headers" after "base" was installed, instead of the need to fulfill "virtualbox" dependencies in one way or the other? What I try to point out is, that "base" not necessarily does cause "bloat", because we are free to remove packages, but "base" could be helpful to avoid being forced to install unwanted packages. Yes, Arch is still Arch without "dhcpd", it anyway belongs to "base". We could turn a blind eye, we aren't an orthodox religion.
Post by Tinu Weber
I do not oppose the idea of having a group of packages that are
*recommended* to be installed - people who don't quite know what they
need can just install that group and assume that they will probably not
run into too much trouble. But people shouldn't be *forced* to install
those packages (or find themselves in the "not supported here!" zone).
If "nano" is installed, the install doesn't become bloated, but it's a kind of standard and some users expect nano to do the very first steps. If you remove nano your Arch still is supported. If "systemd-sysvcombat" isn't installed, then you can't expect that your Arch is supported. The developers perhaps make decisions without that much discussion, just because it's ridiculous to waste time to decide if one or the other package belongs or doesn't belong to "base". Expecting that "base" is installed, is good. It's not really a problem if base contains a few "disputed" packages, this doesn't make a default install bloated.
Post by Tinu Weber
I find a little irony in the fact that you use to pactree/pacman to show
that nothing depends on nano, when the issue here is exactly that
pactree/pacman becomes unreliable for packages in base.
:D

You are right! I made a mistake, but I guess the point I made should be still clear.
Post by Tinu Weber
Of course, nano is tiny, and there is no harm in keeping it around. But
together with all the other packages we don't need, it starts feeling
like clutter. Especially if I have to mentally filter out those packages
from the output of `checkupdates` before I decide whether I want to run
that update, or leave it because it only affects packages I don't use.
I don't have the same "feelings" regarding "clutter" caused by packages from "base" I don't need. I get this feeling for a higher level of software, so I compile some software myself or install empty dummy packages to fulfill dependencies. Should Arch developers really be forced to think that much about what belongs to "base" and what not? "base" isn't bloated and a selection off valid packages, even if one or the other package is disputed. I agree that much likely just less people need reiser tools, but OTOH we could remove the reiser tools and packages with a dependency to reiser tools don't need to mention them as a dependency, so we aren't forced to install dummy packages or build the packages ourself without the reiser tools dependency ;).

Regards,
Ralf
Yardena Cohen via aur-general
2017-03-25 18:26:35 UTC
Permalink
I think we should encourage packagers to name *all* their depends and
makedepends, even if they're in base{,-devel}. Not require (yet) but
encourage.

My problem with this whole discussion is there's no hard data. There's
no clear empirical process for deciding what should be in
base{,-devel}. We only have a circular process: packages shouldn't be
removed because that might break some PKGBUILDs, and PKGBUILDs
continue to omit dependencies because they're implied. And meanwhile
the conversation devolves into bikeshedding about the virtues of nano,
etc.

The only way to break out of this cycle is for packages to start
explicitly naming dependencies. If you have shell scripts, depend on
sh. If you need bash-isms, depend on bash. If you're a daemon with
systemd units, depend on systemd. If you build with git or glibc,
makedepend on those. Once this happens we can inform our arguments
with actual numbers.
Ralf Mardorf
2017-03-26 00:27:52 UTC
Permalink
Post by Yardena Cohen via aur-general
We only have a circular process: packages shouldn't be
removed because that might break some PKGBUILDs, and PKGBUILDs
continue to omit dependencies because they're implied.
Perhaps a good point. I guess this is something the Arch developers have
to decide, so it might be irrelevant what users think. I assume the
developers will discuss this, if they feel the need to do it. This
discussion is about AUR PKGBUILDs. Isn't it? So for the moment...
Post by Yardena Cohen via aur-general
If you're a daemon with systemd units, depend on systemd.
"Init

Warning: Arch Linux only has official support for systemd."

- https://wiki.archlinux.org/index.php/init

...it wouldn't make a difference if systemd is mentioned or not.

In the end you could call all discussions about...

"Before continuing, install the base-devel group. Packages belonging to
this group are not required to be listed as build-time dependencies
(makedepends) in PKGBUILD files. In addition, the base group is assumed
to be installed on all Arch systems." -
https://wiki.archlinux.org/index.php/makepkg

... bikeshedding, since this is a given precondition ;). This isn't the
developers list, it's the Arch _User_ Repository list.

Regards,
Ralf

PS:

FWIW actually I was mistaken, when I mentioned
virtualbox ;), "linux-headers" are just a make dependency and there
already is a solution to avoid issues:

"VIRTUALBOX-HOST-MODULES (virtualbox-host-dkms,
virtualbox-host-modules-arch"
Xyne
2017-03-29 14:28:12 UTC
Permalink
On 2017-03-25 16:31 +0100
Post by Tinu Weber
Post by Ralf Mardorf
A bash script should depend only on bash.
Hi Xyne,
Seems to be better it would depend on coreutilsor do you asume a bash
script only depends on bash intern commands and woun't use external
commands such as e.g. basename?
In such a case, yes, the application should state that it depends on
coreutils. I don't see an issue, though, other than "I don't want to
type that".
I was going to say the same thing before I saw Tinu's reply. My example of a
bash script was bad given that most bash scripts will indeed depend on
coreutils. coreutils is one of the packages that I think should be assumed in a
minimal system btw.
Post by Tinu Weber
Post by Ralf Mardorf
It is still up to the user to decide which packages to install even if
base is recommended. If you don't use nano or lvm, there is no need to
install those packages, for example.
A user always is allowed to customize the install. On my install are
even some hard dependencies missing, but on another software level,
not on the base level. The Arch community needs to share some base
system. If we wouldn't, we wouldn't need Arch related mailing lists.
There must be something in common to call Arch "Arch".
I don't think that the Arch community or the OS itself is solely defined
by an arbitrarily selected set of packages that are expected to be
installed. After all, the systems still share the package manager and
the origin of the packages (created and provided by Arch devs) + the
general idea of KISS (e.g. upstream as unpatched as possible, no partial
upgrade support, ...)
1. Packages that are expected to be there to guarantee a minimally
working system in most situations.
2. Packages that are expected to be there to provide a minimally
comfortable working environment to the user.
I agree that people are mixing up two things but I would say that they are

1. Dependency resolution.
2. What constitutes a minimal Arch Linux system.

The second is arbitrary. There is no obvious definition, and it doesn't even
matter with regard to the first. Explicitly providing the necessary metadata
will always work and makes no assumptions. This will benefit all users but
forces a few packages to type a few extra words. Assuming (and thereby
effectively requiring) that an arbitrary set of packages are installed, even
when many of those are unneeded, is a philosophical wart for a minimalist distro
that leads to wasted bandwidth and disk space, or broken dependency resolution
in some common use-cases.

I am actually surprised that there is even an argument for requiring a base
system with packages that many users will never need (and the whole "but anyone
'competent' enough to remove some of those packages can manage their own deps
manually" is not a valid argument: the distro should not make things more
difficult for users who remove unneeded packages). I get that things change,
but it's sad to see people pushing Arch in that direction. Minimalism is one of
Arch's defining features imo.

If packagers do their job (provide package metadata), then pacman can do its
job (dep resolution). It's really that simple. If you absolutely want a minimal
common group with e.g. glibc, coreutils, linux and whatever else is effectively
indispensable, then ok. Even then those packages should be resolved by
pacman/makepkg.

Regards,
Xyne
Giancarlo Razzolini
2017-03-23 01:38:08 UTC
Permalink
Post by Doug Newgard
There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.
But, if at least the maintainers built their packages using a clean chroot, they
would know what they are missing from base to include on depends. I don't think
we need to enforce that rule to the AUR, but it is a rule for repo packages for
a good reason. We could, however, suggest on the wiki, if it isn't already, that
even for the AUR, the *maintainers* build their packages using devtools.

Cheers,
Giancarlo Razzolini
Daniel Micay via aur-general
2017-03-23 02:02:31 UTC
Permalink
Post by Giancarlo Razzolini
Post by Doug Newgard
There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.
But, if at least the maintainers built their packages using a clean chroot, they
would know what they are missing from base to include on depends. I don't think
we need to enforce that rule to the AUR, but it is a rule for repo packages for
a good reason. We could, however, suggest on the wiki, if it isn't already, that
even for the AUR, the *maintainers* build their packages using
devtools.
Cheers,
Giancarlo Razzolini
Doesn't the standard chroot end up with all of base and base-devel or
is that not currently the case?
Doug Newgard
2017-03-23 02:43:29 UTC
Permalink
On Wed, 22 Mar 2017 22:02:31 -0400
Post by Daniel Micay via aur-general
Post by Giancarlo Razzolini
Post by Doug Newgard
There's no specific rule about it. Some packagers will include packages in base
in the depends, some won't. It's completely up to them.
But, if at least the maintainers built their packages using a clean chroot, they
would know what they are missing from base to include on depends. I don't think
we need to enforce that rule to the AUR, but it is a rule for repo packages for
a good reason. We could, however, suggest on the wiki, if it isn't already, that
even for the AUR, the *maintainers* build their packages using devtools.
Cheers,
Giancarlo Razzolini
Doesn't the standard chroot end up with all of base and base-devel or
is that not currently the case?
All of base-devel, but not all of base.
Eli Schwartz via aur-general
2017-03-23 03:25:22 UTC
Permalink
Post by Daniel Micay via aur-general
Doesn't the standard chroot end up with all of base and base-devel or
is that not currently the case?
The "standard chroot" is a help message in makechrootpkg saying
```
The chroot "root" directory must be created via the following
command:
mkarchroot <chrootdir>/root base-devel
```
and corresponding automation in archbuild.

mkarchroot is really just a btrfs/CHROOT_VERSION wrapper around pacstrap...

As I said earlier, perhaps this is something that could/should be rethought?
--
Eli Schwartz
Baptiste Jonglez
2017-03-29 07:32:09 UTC
Permalink
So, I didn't think such a technical question would spark so much passion!
Maybe this discussion should indeed go to arch-dev-public.

In the meantime, I see 4 positions emerge from the discussion:

1) packages in "base" *should* be explicitely listed as dependencies
(either for mere "technical correctness", or because of bloat, i.e. not
everyone wants/needs all packages from "base")

2) packages in "base" *should not* be listed as dependencies (because it
is assumed that all Arch Linux systems have all packages from "base"
already installed)

3) it depends on the maintainer (i.e. there are no guidelines on this question)

4) it depends on the base package in question (e.g. it would be acceptable
to depend on glibc, but not on systemd)


I get the impression that 3) is the current status quo. I find 4) to be
quite strange and subjective, but it could be done (e.g. only allow
library dependency such as glibc, or allow all dependencies except a few
like systemd).

I have two more arguments in favour of 1) or 4), related to technical
correctness:

- when a new version of glibc is released, which packages should be
rebuilt? Without complete dependency information, I don't see how it's
possible to know.

- Assume that all "base" packages are supposed to already be installed,
and thus no other package depends on "base" packages. When a new
package X is added to "base", how is an already-running system supposed
to pick it up if no dependency pulls it in?

Baptiste
Post by Baptiste Jonglez
Hi,
I was pretty confident that "base" packages should be listed as
dependencies in PKGBUILDs, i.e. they are not assumed to be installed (as
opposed to "base-devel" for build dependencies).
This belief is reinforced by the fact that namcap gives dependencies error
E: Dependency glibc detected and not included (libraries ['usr/lib/libc.so.6', 'usr/lib/libcrypt.so.1'] needed in files ['usr/lib/libcli.so.1.9.7'])
But I could not find any documentation about this. On the contrary, this
In addition, the base group is assumed to be installed on *all* Arch
systems.
Am I missing something obvious?
Thanks,
Baptiste
[1] https://wiki.archlinux.org/index.php/Makepkg#Usage
Bruno Pagani via aur-general
2017-03-29 07:55:09 UTC
Permalink
Post by Baptiste Jonglez
So, I didn't think such a technical question would spark so much passion!
Maybe this discussion should indeed go to arch-dev-public.
Probably, since this is not just discussing the AUR policy but packaging at the whole scale.
Post by Baptiste Jonglez
1) packages in "base" *should* be explicitely listed as dependencies
(either for mere "technical correctness", or because of bloat, i.e. not
everyone wants/needs all packages from "base")
That’s what I’m in favour of, but there is another option you’ve forgot about that could potentially suits me as well (see below).
Post by Baptiste Jonglez
2) packages in "base" *should not* be listed as dependencies (because it
is assumed that all Arch Linux systems have all packages from "base"
already installed)
Most of my installs consist of only few base packages installed as explicit, and probably half of base packages not being installed at all. I expect that to be a valid install, and I indeed don’t like bloat.
Post by Baptiste Jonglez
3) it depends on the maintainer (i.e. there are no guidelines on this question)
4) it depends on the base package in question (e.g. it would be
acceptable
to depend on glibc, but not on systemd)
I get the impression that 3) is the current status quo. I find 4) to be
quite strange and subjective, but it could be done (e.g. only allow
library dependency such as glibc, or allow all dependencies except a few
like systemd).
I have two more arguments in favour of 1) or 4), related to technical
- when a new version of glibc is released, which packages should be
rebuilt? Without complete dependency information, I don't see how it's
possible to know.
I think that TODO for rebuilding are determined by looking at ldd output, or at least they could. But I would not make that an argument for removing glibc from depends, it will anyway be indirectly depended on for most packages.
Post by Baptiste Jonglez
- Assume that all "base" packages are supposed to already be installed,
and thus no other package depends on "base" packages. When a new
package X is added to "base", how is an already-running system supposed
to pick it up if no dependency pulls it in?
Which is a very good argument.

Also, from the discussion there is 2.b) option, which consist in additionaly redefining base (and potentially base-devel as well, but let’s keep this separated) to really only consist of the minimal core system (maybe something in the like of pacman, glibc, systemd, linux, a shell, UNIX tools, and their dependencies). But maybe that definition of base would already be controversial/to subjective in which case we’re back to 1) being the only correct solution I would say.

Bruno
LoneVVolf
2017-03-29 10:32:42 UTC
Permalink
Post by Baptiste Jonglez
So, I didn't think such a technical question would spark so much passion!
Maybe this discussion should indeed go to arch-dev-public.
1) packages in "base" *should* be explicitely listed as dependencies
(either for mere "technical correctness", or because of bloat, i.e. not
everyone wants/needs all packages from "base")
2) packages in "base" *should not* be listed as dependencies (because it
is assumed that all Arch Linux systems have all packages from "base"
already installed)
3) it depends on the maintainer (i.e. there are no guidelines on this question)
4) it depends on the base package in question (e.g. it would be acceptable
to depend on glibc, but not on systemd)
I get the impression that 3) is the current status quo. I find 4) to be
quite strange and subjective, but it could be done (e.g. only allow
library dependency such as glibc, or allow all dependencies except a few
like systemd).
I have two more arguments in favour of 1) or 4), related to technical
- when a new version of glibc is released, which packages should be
rebuilt? Without complete dependency information, I don't see how it's
possible to know.
- Assume that all "base" packages are supposed to already be installed,
and thus no other package depends on "base" packages. When a new
package X is added to "base", how is an already-running system supposed
to pick it up if no dependency pulls it in?
Baptiste
It looks like many here haven't looked at base group in a while,
or don't distinguish between base group and core repository.

example :
systemd-sysvcompat is in base, systemd is NOT .
Both are in core repo .

LW
Tharre via aur-general
2017-03-30 19:19:41 UTC
Permalink
Post by LoneVVolf
It looks like many here haven't looked at base group in a while,
or don't distinguish between base group and core repository.
systemd-sysvcompat is in base, systemd is NOT .
Both are in core repo .
LW
systemd-sysvcompat depends on systemd (obviously), thus systemd is
effectively part of the base group. So I don't really get your point?

--
PGP ID: 0xC8F0B2F4

Giancarlo Razzolini
2017-03-29 12:05:47 UTC
Permalink
Post by Baptiste Jonglez
So, I didn't think such a technical question would spark so much passion!
Maybe this discussion should indeed go to arch-dev-public.
1) packages in "base" *should* be explicitely listed as dependencies
(either for mere "technical correctness", or because of bloat, i.e. not
everyone wants/needs all packages from "base")
This is the only valid option.
Post by Baptiste Jonglez
2) packages in "base" *should not* be listed as dependencies (because it
is assumed that all Arch Linux systems have all packages from "base"
already installed)
Wrong.
Post by Baptiste Jonglez
3) it depends on the maintainer (i.e. there are no guidelines on this question)
If you build using devtools, this become quite obvious.
Post by Baptiste Jonglez
4) it depends on the base package in question (e.g. it would be acceptable
to depend on glibc, but not on systemd)
Dependencies are dependencies. You can pull in a chain, by bringing the last
link of it, so you don't have to list all of them. But you need to explicitly
put everything you need for the program to build, test and run. Either this be
on base, base-devel or on repos, core, extra, community.
Post by Baptiste Jonglez
I get the impression that 3) is the current status quo. I find 4) to be
quite strange and subjective, but it could be done (e.g. only allow
library dependency such as glibc, or allow all dependencies except a few
like systemd).
I have seem packages on the repos that failed to build using a clean chroot[0].
I reported and they were fixed.
Post by Baptiste Jonglez
I have two more arguments in favour of 1) or 4), related to technical
- when a new version of glibc is released, which packages should be
rebuilt? Without complete dependency information, I don't see how it's
possible to know.
There are tools for finding this. But this should really be on the package
dependency list. Keep in mind that only packages that link directly to it
need to be rebuilt (mostly).
Post by Baptiste Jonglez
- Assume that all "base" packages are supposed to already be installed,
and thus no other package depends on "base" packages. When a new
package X is added to "base", how is an already-running system supposed
to pick it up if no dependency pulls it in?
base is an arbitrary set of packages, as this whole discussion showed us, in
abundance. And it's not like pulling base will hurt you, but not everyone
needs/wants to pull it in. Explicit dependency (chain considered) is the only
way.

[0] https://bugs.archlinux.org/task/51613
Continue reading on narkive:
Loading...