Re: Facilitating external repositories
Wouter Verhelst wrote:
> At $DAYJOB, I'm maintaining a few repositories with ready-to-install
> packages for a number of distributions[1]
>
> Currently, the instructions[2] say to do the following:
> - Download and install an "eid-archive" package, which contains the GPG
> keys and generates a sources.list.d file for the repository;
> - Run "apt-get update";
> - Install the "eid-mw" and/or "eid-viewer" packages.
>
> This works, but it has a number of downsides:
> - The second step, "run apt-get update", is often overlooked; this seems
> to be the case especially for users of Ubuntu, where the default
> handler for installing packages is the "Software Center", a GUI
> software management tool that doesn't have any UI element for doing
> (the equivalent of) apt-get update
> - There is no trust path from your already-installed distribution to the
> "archive" package (yes, I did sign the gpg keys; no, I don't consider
> that enough).
> - It still requires users to manually install packages.
Given that the packages in question appear to be Free Software (at least
from a quick check of a couple of them, as well as the repository being
named "main"), is there a reason you don't maintain them in Debian
(including backports or volatile if you need to provide the newest
packages for older distributions)?
If that's not an option for some reason, then given that the packages
are Free Software and of reasonably broad interest, you could at least
upload a package to Debian containing the archive key, similar to
pkg-mozilla-archive-keyring; that would establish a trust path. (Which
doesn't solve the usability problem, but it does solve the trust
problem.)
I don't think you can have a dpkg trigger run apt update, since dpkg
will typically be invoked under the apt lock. However, a higher-level
package manager that doesn't support manual updates could probably learn
to do an update when sources.list{,.d/*} gets updated.
> I note that other third-party developers often provide a single debian
> package that can be installed, where the binary package itself already
> contains repository configuration that gets installed. This method
> works for application software, but (as in my case) if the intent is to
> provide a library that wants to support multiarch, this approach doesn't
> work.
And presumably factoring that out into a "common" package that other
packages depend on won't help, because then you don't have a single
installable package, so you go back to needing a repository.
> [1] specifically, https://files.eid.belgum.be/
Did you mean https://files.eid.belgium.be/ Because the URL you posted
doesn't work with https, and the http version looks shady.
- Josh Triplett
Reply to: