Go package dependencies

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Go package dependencies

tur-users mailing list
Hi there,

I am co-maintaining a few AUR packages written in Golang and I just ran
namcap on my built package. I got the following output on a few of my
golang packages:

$ namcap influxdb-1.4.3-1-x86_64.pkg.tar.xz
influxdb E: Dependency glibc detected and not included (libraries
['usr/lib/libpthread.so.0', 'usr/lib/libc.so.6'] needed in files
['usr/bin/influx_inspect', 'usr/bin/influx_stress', 'usr/bin/influx',
'usr/bin/influx_tsm', 'usr/bin/influxd'])

However 'glibc' is in the base group, and I thought that it wasn't
necessary to declare dependencies from the base group since it should
always be installed on a fresh OS install. Am I wrong about this point?
Should I be including 'glibc' as a dependency in this package? Should I be
including 'bash' as a dependency in packages with scripts that use bash?

Thank you!
Adam Levy (alaskanarcher)
Reply | Threaded
Open this post in threaded view
|

Re: Go package dependencies

tur-users mailing list
On 02/28/2018 02:23 AM, Adam Levy via aur-general wrote:

> Hi there,
>
> I am co-maintaining a few AUR packages written in Golang and I just ran
> namcap on my built package. I got the following output on a few of my
> golang packages:
>
> $ namcap influxdb-1.4.3-1-x86_64.pkg.tar.xz
> influxdb E: Dependency glibc detected and not included (libraries
> ['usr/lib/libpthread.so.0', 'usr/lib/libc.so.6'] needed in files
> ['usr/bin/influx_inspect', 'usr/bin/influx_stress', 'usr/bin/influx',
> 'usr/bin/influx_tsm', 'usr/bin/influxd'])
>
> However 'glibc' is in the base group, and I thought that it wasn't
> necessary to declare dependencies from the base group since it should
> always be installed on a fresh OS install. Am I wrong about this point?
> Should I be including 'glibc' as a dependency in this package? Should I be
> including 'bash' as a dependency in packages with scripts that use bash?
>
> Thank you!
> Adam Levy (alaskanarcher)
>
Actually there is no strict rule that base must be installed, its just a
strong recommendation. While most systems would be quite useless without
having glibc, its still a first level dependencies that a package uses
and therefor should be declared explicitly and not implicitly.
Opinions vary, but if you ask me its cleaner to explicitly state first
level dependencies, no matter from where they may be implicitly
available (so yes, personally i add both, glibc and bash if required).

cheers,
Levente


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Go package dependencies

tur-users mailing list
Good to know. I will update my PKGBUILDs accordingly.

Thank you

On Tue, Feb 27, 2018 at 4:33 PM, Levente Polyak via aur-general <
[hidden email]> wrote:

> On 02/28/2018 02:23 AM, Adam Levy via aur-general wrote:
> > Hi there,
> >
> > I am co-maintaining a few AUR packages written in Golang and I just ran
> > namcap on my built package. I got the following output on a few of my
> > golang packages:
> >
> > $ namcap influxdb-1.4.3-1-x86_64.pkg.tar.xz
> > influxdb E: Dependency glibc detected and not included (libraries
> > ['usr/lib/libpthread.so.0', 'usr/lib/libc.so.6'] needed in files
> > ['usr/bin/influx_inspect', 'usr/bin/influx_stress', 'usr/bin/influx',
> > 'usr/bin/influx_tsm', 'usr/bin/influxd'])
> >
> > However 'glibc' is in the base group, and I thought that it wasn't
> > necessary to declare dependencies from the base group since it should
> > always be installed on a fresh OS install. Am I wrong about this point?
> > Should I be including 'glibc' as a dependency in this package? Should I
> be
> > including 'bash' as a dependency in packages with scripts that use bash?
> >
> > Thank you!
> > Adam Levy (alaskanarcher)
> >
>
> Actually there is no strict rule that base must be installed, its just a
> strong recommendation. While most systems would be quite useless without
> having glibc, its still a first level dependencies that a package uses
> and therefor should be declared explicitly and not implicitly.
> Opinions vary, but if you ask me its cleaner to explicitly state first
> level dependencies, no matter from where they may be implicitly
> available (so yes, personally i add both, glibc and bash if required).
>
> cheers,
> Levente
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Go package dependencies

tur-users mailing list
> On Tue, Feb 27, 2018 at 4:33 PM, Levente Polyak via aur-general <
> [hidden email]> wrote:
>> Actually there is no strict rule that base must be installed, its just a
>> strong recommendation. While most systems would be quite useless without
>> having glibc, its still a first level dependencies that a package uses
>> and therefor should be declared explicitly and not implicitly.
>> Opinions vary, but if you ask me its cleaner to explicitly state first
>> level dependencies, no matter from where they may be implicitly
>> available (so yes, personally i add both, glibc and bash if required).

On 02/27/2018 08:48 PM, Adam Levy via aur-general wrote:
> Good to know. I will update my PKGBUILDs accordingly.
>
> Thank you
>

Whereas I in contrast believe that glibc and bash even as first level
dependencies make no sense to add, due to the fact that *all*, not
*most* systems would be useless without it, since glibc is used for
literally everything and if you rebuild the entire distro to use musl
libc or something then you are no longer using something even vaguely
resembling Arch Linux. (And if you want to do so anyway then your
toolchain probably pulls in musl automatically, and adding a dependency
on glibc just because the default compiler for makepkg uses glibc would
be wrong from the perspective of the PKGBUILD.)

So as Levente said, there are no real rules anywhere here. I like to
think that the reason namcap warns about glibc is only because it would
need to be explicitly excluded, and no one can agree on what to do here.

So, disregard namcap entirely, as it is often wrong about *lots* of
things, and ask yourself if you really think it makes sense to list
glibc here.

...

FWIW I understand where Levente is coming from in the general sense with
regard to first-level dependencies that are implicitly available due to
another dependency -- those can often cause issues when the other
dependency unexpectedly drops its own dependency.

I just think glibc, bash, coreutils, util-linux, and other similar
packages should be a special exception. ;)

Maybe one day we will actually decide on a "base-sytem" metapackage that
guarantees that all Arch systems have these available. Until then, this
is really a bikeshed discussion.

--
Eli Schwartz
Bug Wrangler and Trusted User


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Go package dependencies

tur-users mailing list
Having heard both sides of the coin here I think I lean toward agreeing
with Eli in this case. And as it appears to be partly a matter of personal
taste anyway, I'll be leaving the dependencies as is.

Thank you both for your replies.

On Tue, Feb 27, 2018 at 5:05 PM, Eli Schwartz via aur-general <
[hidden email]> wrote:

> > On Tue, Feb 27, 2018 at 4:33 PM, Levente Polyak via aur-general <
> > [hidden email]> wrote:
> >> Actually there is no strict rule that base must be installed, its just a
> >> strong recommendation. While most systems would be quite useless without
> >> having glibc, its still a first level dependencies that a package uses
> >> and therefor should be declared explicitly and not implicitly.
> >> Opinions vary, but if you ask me its cleaner to explicitly state first
> >> level dependencies, no matter from where they may be implicitly
> >> available (so yes, personally i add both, glibc and bash if required).
>
> On 02/27/2018 08:48 PM, Adam Levy via aur-general wrote:
> > Good to know. I will update my PKGBUILDs accordingly.
> >
> > Thank you
> >
>
> Whereas I in contrast believe that glibc and bash even as first level
> dependencies make no sense to add, due to the fact that *all*, not
> *most* systems would be useless without it, since glibc is used for
> literally everything and if you rebuild the entire distro to use musl
> libc or something then you are no longer using something even vaguely
> resembling Arch Linux. (And if you want to do so anyway then your
> toolchain probably pulls in musl automatically, and adding a dependency
> on glibc just because the default compiler for makepkg uses glibc would
> be wrong from the perspective of the PKGBUILD.)
>
> So as Levente said, there are no real rules anywhere here. I like to
> think that the reason namcap warns about glibc is only because it would
> need to be explicitly excluded, and no one can agree on what to do here.
>
> So, disregard namcap entirely, as it is often wrong about *lots* of
> things, and ask yourself if you really think it makes sense to list
> glibc here.
>
> ...
>
> FWIW I understand where Levente is coming from in the general sense with
> regard to first-level dependencies that are implicitly available due to
> another dependency -- those can often cause issues when the other
> dependency unexpectedly drops its own dependency.
>
> I just think glibc, bash, coreutils, util-linux, and other similar
> packages should be a special exception. ;)
>
> Maybe one day we will actually decide on a "base-sytem" metapackage that
> guarantees that all Arch systems have these available. Until then, this
> is really a bikeshed discussion.
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Go package dependencies

tur-users mailing list
In reply to this post by tur-users mailing list
Le 28/02/2018 à 03:05, Eli Schwartz via aur-general a écrit :

> I just think glibc, bash, coreutils, util-linux, and other similar
> packages should be a special exception. ;)
>
> Maybe one day we will actually decide on a "base-sytem" metapackage that
> guarantees that all Arch systems have these available. Until then, this
> is really a bikeshed discussion.

This is going to happen, we have already extensively discussed this and
now we are just waiting for that person who said he wanted to take care
to write on adp about this do actually do so. ;)


signature.asc (531 bytes) Download Attachment