[Debian package] APT repository suite configuration

RogueScholar

Congratulations on arriving at the auspicious milestone of the first stable release for the Linux app! I've witnessed first-hand the polishing that's taken place on it and couldn't agree more that it's ready for primetime; all of the minor quibbles that existed when I first started using it have been resolved and now it just "works." :)

I would like to raise one very trivial concern though regarding the Debian packaging, after just having installed the stable release over the most recent beta, while it's fresh in my mind. I noticed (by way of etckeeper) that the stable package overwrites the 1password.list file in /etc/apt/sources.list.d so that only the "stable" suite remains. While I can appreciate why you might wish to migrate the early adopters away from the development release channels, making changes to files under /etc (which the FHS 3.0 classifies as the province of the system administrator) without user interaction/confirmation doesn't feel right to me. I can think of a couple different ways the file could be changed as part of the upgrade path more transparently without (I think) being pedantic, and I hope you won't mind me enumerating them here unbidden.

1. The simplest approach would be to register the 1password.list file as a conffile of the package by adding its canonical path to debian/conffiles in the source package. Doing so causes dpkg to hash the file upon install and thereafter when changes are included with subsequent package releases, the user will be prompted to accept or reject them and is offered a diff to inform them of the intended changes. This would also necessitate adding the 1password.list file to the package contents proper as opposed to the current approach of redirecting stdout to the file from the postinst maintscript.
2. The more intricate approach (and more elegant, IMO) would be to make use of the debconf menu system to present the user with the option to enable/disable all possible release "suites" (stable/beta/edge) and include a 1password.list file in the package contents that included a line for each suite but all commented out, so that the user's choices made in debconf would be tied to a shell script function that used some basic "sed-fu" to strip the comment characters from the lines the user wished enabled.
3. In the interest of fairness, I'll acknowledge that there is one other approach that I could see working and seems to be the preference of a handful of dev teams (Teamviewer is the only one I can think of at the moment I'm certain about, but I believe Plex does this too, among others), though it's not how I would do things. Specifically, they don't handle APT repository configuration as part of the package itself, but rather as a subcommand of their CLI (which no doubt is just an embedded set of shell script functions nearly identical to the "sed-fu" I alluded to re: debconf). This would also probably necessitate putting together a separate package for the CLI binary or adding it to the existing GUI package, either of which would be awesome. A pro forma implementation model based on Teamviewer's approach would add a repo subcommand to op, whose help output might look like:

...
op repo                      show current repository configuration
op repo list                list available packages
op repo default         restore default configuration
op repo disable         disable repository updates
op repo stable           make all regular 1Password packages available (default)
op repo beta              additionally, make feature preview packages available
op repo edge             additionally, make nightly build packages available

Anyhow, this post is already too long so I'm gonna wrap it up here. I only went into as much details as I did here out of a sense of respect for your time and expertise; I detest being on the receiving end of feature/functionality requests with an implicit expectation that I research the basics of the possible implementations and so tried my best not to do that to you here. Should you want to discuss this further at any point, though, I'm at your disposal through all the usual channels.

Cheers,
Peter

---

1Password Version: 8.1.0
Extension Version: 1.25.7
OS Version: Kubuntu 21.04 (5.11.0-18-generic)
Sync Type: Not Provided

James.Dressel_1P

Hi Peter,

Thank you, this is an excellent suggestion, and a thorough write-up. I appreciate your attention to detail, and providing references. Frankly, I was pretty excited when I read your post yesterday. I wanted to prototype this before responding, but I haven't gotten around to that yet.

To provide some background context, there are two reasons that we edit /etc/apt/sources.list.d/1password.list. Our primary motivation is to avoid "stranding" users on old versions of 1Password. Someone who installs using the command line instructions would automatically be setup for future updates. We wanted to make sure someone who installs by downloading and double clicking on the deb (or rpm) file has a similar experience, and does not need to worry about getting updates.

Another reason for the current postinst script was re-directing our (very) early adopters to the repo on https://downloads.1password.com/. Early in our linux development we had a different location for our apt repo, and we didn't want to leave anyone behind on the old location.

I believe your suggested approaches would continue to satisfy the above requirements. I can't commit to a timeline, but this is something I will discuss with our other developers. Assuming we implement this, I expect we'd go with approach #1. Keep the install process streamlined, while providing an easy method to get future updates.

As an aside, we've discussed a similar proposal to #3. Weren't sure we covered all the edge cases, and have held off. It's an idea that we'd like to revisit though.

Best wishes,

James Dressel