[BIKESHED] curl license file location

[the-maldridge]

In re-imagining what build infrastructure around xbps-src looks like, having the ability to run lots of things inside the ethereal chroot becomes appealing. Everything I've wanted to do so far has worked, but for doing an HTTP post of files it would be ideal to have curl in the chroot. Thoughts on adding a chroot-curl ?

[Chocimier]

Do we need it? (lib)curl is already part of stage2 base-chroot, and stage0 base-chroot isn't used for anything but producing stage1.

https://github.com/void-linux/void-packages/runs/4021578772?check_suite_focus=true#step:3:35

[q66]

i'd sooner be in favor of removing network access from the chroot than further depending on it

[the-maldridge]

@Chocimier I want the binary in the ethereal masterdir, I can just add it there, but I'm not sure if there's a problem with doing that if it will cause curl to be picked up in places it shouldn't be.

@q66 I encourage you to try. I don't care about calling curl from inside of xbps-src's managed chroots, I only care about having the binary available.

[q66]

if you don't care about calling it, why have it available in the first place?

[ericonr]

Purpose of chroot-curl afaiu is to perform maintenance tasks after xbps-src has done its thing.

A smaller package is easier to build / maintain (could depend only on OpenSSL), and it would always be available, but without a library and with a different executable name to avoid any silliness in configure scripts from picking it up.

[Chocimier]

What @ericonr proposes looks fine, but it's discussion on solution when problem wasn't stated.

Requested bikeshedding: why not to install [regular] curl after xbps-src is done?

[the-maldridge]

@Chocimier the use case is to POST package files and logs back after builds complete. In this case installing curl after xbps-src is done would result in it being installed for every build, which while a relatively trivial load on the internal mirror would be slow and inefficient over using a pre-cached filesystem image that already includes curl.

This could also be done as a package that is not depended on by anything and gets added to the ethereal masterdir during a build step to keep it out of local chroots and environments where its presence is not required.

[ericonr]

I think the most important detail here is for bootstrapping builders. You can't install curl afterwards if it hasn't been built yet, but it works if chroot-curl is part of the bootstrap set.

[sgn]

IYou can't install curl afterwards if it hasn't been built yet

libcurl is in stage 2 chroot, so it's built definitely.

If we want to provide it in builders, we can put current curl binary somewhere not in $PATH?

[sgn]

Anyway, I notice license is distributed with curl package instead of libcurl package. So, we're doing copyright infringement by distribute libcurl without the copyright notice and condition?

[q66]

not particularly, arguably it's not required to ship the license files at all (e.g. Alpine does not ship them, with the claim being that the SPDX tags are enough)

but even then, the distribution of the software includes all subpackages, it should not be necessary to include the license in all of them

[sgn]

but even then, the distribution of the software includes all subpackages, it should not be necessary to include the license in all of them

I'm not advocate to include the license in all of them, but ship the license with libcurl instead of curl

[ericonr]

I'm not advocate to include the license in all of them, but ship the license with libcurl instead of curl

I think that's reasonable.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.