On Fri, Jun 05, 2015 at 09:10:56AM -0700, Josh Triplett wrote:
> 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"),
Correct, it's all under GPLv3.
> 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)?
As others have pointed out, the said software used to be in Debian (I
was its maintainer). The reasons for pulling it were long, complicated,
and boring; suffice to say that there were some practical problems.
(the ftp.d.o bug says "no reply from maintainer", which is only half the
story. At the time I was aware of issues starting to build around beid,
and trying to figure out how to fix them; I should've probably replied,
but it occurred to me that pulling was probably a good strategy, at
least in the short term)
> 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.)
True, but I don't think it is the best way forward.
First, it would work for me, as long as I'm still contracting for the
government[1]. However, due to it being a *government* contract, this is
an inherently time-limited situation[2]. I want this situation to remain
manageable after the end of my contract.
Second, while I wrote this in response to an immediate issue that I'm
dealing with, it should obvious that this isn't a problem specific to my
situation; I would prefer to have a situation which works for everyone,
not just for me. Having to maintain a package inside Debian isn't the
best solution for third-party developers.
Third, this wouldn't scale very well. I think the
pkg-mozilla-archive-keyring is special in that it contains pre-release
packages of software already in Debian, maintained by the same people
who maintain that software in Debian. This is not the case for my
software, and presumably also not for many other third-party
repositories.
Finally, requiring third-party developers to upload an archive keyring
into Debian does not scale very well.
Other operating systems (Windows, OSX) have a way for third-party
developers to get a key signed which is then allowed to install software
without big red flashing security warnings. I think it would make sense
for us to have something similar. We currently don't; in fact, when you
install something that isn't signed, you *don't* get big red flashing
security warnings; I think that's wrong, and that we should do so.
[1] Technically, I'm not contracting for the government, there's a
middle man in there somewhere, but let's keep the pesky little
details out of it, shall we? ;-)
[2] Belgian law says that while the government can employ contractors,
every few years the contract has to be renegotiated; at that point I
could continue working, or someone else could win the contract and
take over.
> I don't think you can have a dpkg trigger run apt update, since dpkg
> will typically be invoked under the apt lock.
Actually, I believe the story is that apt wants to invoke the dpkg lock
;-)
At any rate, no, that doesn't work. Yes, I tried.
> 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.
Exactly.
> > [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.
Yes, that was a typo, sorry.
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Attachment:
signature.asc
Description: Digital signature