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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150605161051.GA1471@jtriplet-mobl1