[aur-general] TU Application - blakkheim
Levente Polyak
anthraxx at archlinux.org
Sun Aug 28 22:25:38 UTC 2022
On 8/25/22 17:40, Konstantin Gizdov via aur-general wrote:
> On 25/08/2022 18:08, T.J. Townsend via aur-general wrote:
>> It can be a little confusing for new users because the tooling will print
>> warnings about this:
>>
>> openiked W: Dependency glibc included but already satisfied
>> openiked W: Dependency openssl included but already satisfied
>>
>> But Arch's packaging policy says "Do not rely on transitive dependencies
>> in any of the PKGBUILD#Dependencies, as they might break if one of the
>> dependencies is updated."
>>
>> These two things seem to be in conflict with each other, so I went with
>> the policy statement as the deciding rule.
> Sure, but the issue is that 'glibc' is in the 'base' group that will
> exist on any Arch Linux install. There is a bit of debate whether we
> include these or not. Most people normally do not as it's a given on any
> system. In any case, 'glibc' is not really a transitive dependency in
> that sense.
>
I'd disagree here. I do not like to threat a hand full of packages any
special just because its virtually impossible to run a system without.
Its a much easier and better model to declare all primary runtime
dependencies.
Glibc is only special because its glibc, not because its in base. The
'base' meta package is a meta package for a reason. It can change at any
point in time reflecting what we currently declare as a base minimum for
a system to be called "Arch Linux". It's quite a bad trade trying to
spend a couple of less characters in an depends array when this base
package may theoretically change at any point in time -- which should
not lead to any packaged need any adjustments. In that sense glibc is
only special because you won't in fact run a system without glibc.
Either way my stance is easy: There is no reason trying to declare any
packages as special in terms of not needing to declare them. It brings
up the burden to remember or argue while in fact it brings absolutely no
advantages to omit it -- but on the other hand potential scenarios where
it creates issues. Hence just declare whatever the package actually
needs and call it a day. I'd say that sounds more like keeping is simple
stupid.
cheers,
Levente
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20220829/431efcdf/attachment.sig>
More information about the aur-general
mailing list