Rclone is 4 years outdated

The package "rclone" has not been updated in a long time. I did not find any open bug reports about it.

I was brave and tried to run the latest myself using:

`guix build rclone --with-source=rclone@1.66.0=./rclone-1.66.0.tar.gz`

With the latest source tarball from the Github release. The recipe (in sync.scm) uses a tar download rather than a git-fetch for some reason, so I wasn't able to reuse the recipe with --with-branch. (Btw --with-version would be nice to have, since the version's download URL is done correctly in the recipe.)

Unfortunately I ran into some obscure build error and don't know how to proceed as this is outside of my familiarity.

Ni! Using `--with-latest` and using `--with-version` also fails during build.

Build log is attached.

I've never played with the go build system, but it seems that the definition doesn't include the required dependencies.

There's a comment in the current outdated definition saying that dependencies are bundled with the tarball. Looking at current files that no longer seems to be the case. I'm assuming --with-latest and --with-version just download newer tarballs.

There seems to be many dependencies. I have no idea whether they're all in guix, so I wonder how hard would it be to fix this. And if it's really only the dependencies that are missing from the definition.

.~´

Hi,

Thanks for reporting.

<2020-08-08> in Guix

<2025-01-14> the current latest release

The project changed the module of release and now ships vendor and source separatly:

- https://github.com/rclone/rclone/releases/download/v1.69.0/rclone-v1.69.0-vendor.tar.gz

- https://github.com/rclone/rclone/releases/download/v1.69.0/rclone-v1.69.0.tar.gz

It means we need to package all missing inputs before update to the

latest.

CC Leo for the second opinion if we may grab vendor and ingest it

during build and initiate packaging for the future to reduce amount of

vendored packages.

--

Oleg

On Tue, Feb 04, 2025 at 09:37:05AM +0000, Sharlatan Hellseher wrote:

I see.

I think it's fine to use this vendored / bundled tarball.

Using the vendored code is not the Guix way, but we are already using

the bundled dependencies for this package.

The change is that now they are provided in a separate tarball.

This is not a meaningful change with respect to the why Guix generally

doesn't use bundled source code and I don't think the code review

process for this update should force them to be unbundled now.

In the past I've argued that the way we handle Go packages right now is

insufficient to package them properly. Either we could make an easy to

parameterize Go libraries / modules so that they are not vendored

(improve the importer as part of that?), or just use the vendored code.

But I always say that motivation is not fungible. If you are interested

in packaging these dependencies in the future, go for it!