Re: [aur-general] Go package dependencies

[Adam Levy via aur-general]

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 <
aur-general@archlinux.org> wrote:

> > On Tue, Feb 27, 2018 at 4:33 PM, Levente Polyak via aur-general <
> > aur-general@archlinux.org> 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
>
>

Re: [aur-general] Go package dependencies

[Eli Schwartz via aur-general]

> On Tue, Feb 27, 2018 at 4:33 PM, Levente Polyak via aur-general <
> aur-general@archlinux.org> 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
Description: OpenPGP digital signature

Re: [aur-general] Go package dependencies

[Adam Levy via aur-general]

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 <
aur-general@archlinux.org> 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
>
>

Re: [aur-general] Go package dependencies

[Levente Polyak via aur-general]

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
Description: OpenPGP digital signature

[aur-general] Go package dependencies

[Adam Levy via aur-general]

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)

Re: [aur-general] aur-out-of-date: determine out-of-date AUR packages w.r.t. upstream

[Rafael Fontenelle]

2018-02-27 20:05 GMT-03:00 Adam Levy via aur-general
:
> Neat program!
>
> It currently doesn't handle release candidate version tags. For example,
>
> $ aur-out-of-date -pkg influxdb
> [OUT-OF-DATE] [influxdb] Package influxdb should be updated from 1.4.3-1 to
> 1.5.0rc4
>
> It might be worth adding an option to ignore version tags that end in
> 'rc*'. Or perhaps make that the default and add a flag to *not* ignore
> release candidate tags. I'm sure there are other conventions for post-fixes
> on version tags that indicate pre release or testing status. Maybe a more
> flexible way to go would be to offer an environment variable or option for
> setting a list of regexes to disregard if matched.
>
>
> Thanks!
> Adam Levy

Hello Adam,

You might want to report this suggestion to the upstream:
https://github.com/simon04/aur-out-of-date/issues

Best regards,
Rafael Fontenelle

Re: [aur-general] aur-out-of-date: determine out-of-date AUR packages w.r.t. upstream

[Adam Levy via aur-general]

Neat program!

It currently doesn't handle release candidate version tags. For example,

$ aur-out-of-date -pkg influxdb
[OUT-OF-DATE] [influxdb] Package influxdb should be updated from 1.4.3-1 to
1.5.0rc4

It might be worth adding an option to ignore version tags that end in
'rc*'. Or perhaps make that the default and add a flag to *not* ignore
release candidate tags. I'm sure there are other conventions for post-fixes
on version tags that indicate pre release or testing status. Maybe a more
flexible way to go would be to offer an environment variable or option for
setting a list of regexes to disregard if matched.


Thanks!
Adam Levy