OK to contribute packages that DL binaries?

grumbly

Hi, I've read that some packages are not okay to package and host in solus repos, such as MegaSync or Slack, and that makes common sense. Sometimes a particular software is available in Third-Party, like Slack. I personally prefer downloading the provided binary tarballs from each organization and "installing" them myself and making a .desktop file manually. This typically comes with the benefit of better hardware support (like for Zoom) and a smaller total install footprint. Toward this end I keep some scripts around that install these various freely available pieces of software by automating my installation method for tar, rpm, and deb files from various organizations. Is it A) allowable B) is there any interest, in having eopkg "packages" that grab a pre-made freely available linux binary and install it for the user? For instance, an eopkg package that automates downloading, unpacking, and installing VSCode, along with any lib dependencies it may need. For example, Empty Epsilon needs a couple libraries to run, but otherwise the .deb package works well. Okay, Empty Epsilon is open source and could be made a proper package, but you get the idea.

Harvey

Simply extracting packages made for another distribution like a .deb to / can not be done universally in a safe way. It is possible they could overwrite files, cause conflicts / breakages. Care needs to be taken on a per package basis. In my opinion full automation of packaging is always a bad idea.

However Solus does sometimes repackage .deb's to make an .eopkg. It is usually only for closed source applications where only a .deb package is provided. Like everything in the 3rd party section of the software center or vivaldi which is in the repository proper https://dev.getsol.us/source/vivaldi-stable/browse/master/package.yml$5 This was not generated automatically and gets reviewed.

If a user wants to download random .deb's and try their luck, they are far better off downloading the .deb and extracting it to a user controlled directory such as their home directory, which the package manager will never touch and would not require any automation because they can just delete it, download the new version and extract it again to the same location.

You can of course do whatever you want on your system but it would be unsupported. Meaning if you break anything you are on your own fixing it. So I would not advise you share these scripts on the forums.

grumbly

@Harvey Thanks so much for the detailed reply! I think the conclusion is "no" there's no good way to automate installing third-party apps for other Solus users. To clarify though, I didn't mean making something that allows installation of arbitrary packages, or creates eopkg packages automatically, but an eopkg package hand-built specifically to install for instance MegaSync. We'd get around hosting legality by simply downloading Mega's Fedora package straight from their domain as part of the package script. And I only was thinking relocatable packages so there are no problems with path issues. I did try a deb that wasn't relocatable, and found that Solus didn't use the important paths (/usr/local), so there was no conflict when I installed it, but I'm pretty green to these things.

Too bad eopkg doesn't have a --user space option like pip install --user.

Staudey

grumbly Yes, that seems a lot like the mechanism for the Third Party Repository, which we don't accept new inclusions for. In general we wouldn't want to enter any legal gray zones. For everything that works like Vivaldi, which has no restrictions about hosting the code, the same mechanism would apply (i.e. regular inclusion into the main repository with a package.yml that extracts and modifies the .deb file)

But when it comes to things like your example MegaSync, it's a bit more complicated. The initial package request for it ended with DataDrake finding the following in their license:

Other than in respect of those parts of the code that were developed by other parties and as specified strictly in accordance with the open source and other licences under which those parts of the code have been made available, as set out on our website or in those items of code, you are not entitled to use or do anything with the code for any commercial or other purpose, other than review and commentary on it.

"Not entitled to use or do anything with the code" seems extremely restrictive, and would also seem to exclude providing a script that downloads and extracts their code. Weird terms in any case, but what can one do.