[pacman-dev] RFC: 'repo-add' command for repository discovery
Hi Everyone, I have been thinking about the creation of a tool similar to Ubuntu's add-apt-repository, allowing some automation of the repository adding process inside Arch Linux. My thoughts at the moment would be to create a simple bash script (`repo-add`?) that would get the TXT record for the second command line argument. For example, I could run: repo-add packages.timg.ws The script would then get the TXT record for packages.timg.ws. That TXT record would point to a .conf file that contains all of the configuration for the "packages.timg.ws" repository. That .conf file would be downloaded, and then placed into /etc/pacman.d My thinking is that this command would set up the pacman configuration, and check that everything is OK. If the .conf file contains as a comment with the fingerprint and location of a public key, then `pacman-key` can additionally be automated, maybe showing a message showing what the fingerprint is and that the gpg key downloaded from the comment on the .conf file matches that of the public key. Additionally, a .conf file from the TXT record could also suggest that packages get installed straight after the repo-add command has been ran. If the second command is a URI, then either that file could be downloaded (skipping the "discovery" of a repository), or just the host could be extracted from the URI allowing the discovery to go back to the TXT record. Having this command use the TXT record has two awesome advantages: 1. My site (eg, packges.timg.ws) could be hosted on a different server to where the packages are. 2. No more copying & pasting a whole bunch of configuration to add a repository. Example Run: # repo-add packages.timg.ws 1. The script dig's the hostname that was entered as the second argument on the script: # dig TXT packages.timg.ws +short "http://timg.ws/archlinux/repo/timgws.conf" 2. The .conf file is downloaded. 3. The GPG key shown in the .conf file is downloaded 4. Fingerprint matched, OK (here there would be a warning if the fingerprint of key != fingerprint in conf) 5. Fingerprint shown, confirmation requested 6. conf added to pacman, if packages are suggested, show what they are, ask to run pacman -Su <packages> 7. ??? 8. Profit! Please let me know your thoughts. Tim
Could you please try not to inadvertently run into a name conflict with the very project you're talking about? See [0]. cheers! mar77i [0] https://www.archlinux.org/pacman/repo-add.8.html
This is why it's in quotes, I didn't mean to suggest that repo-add would be the final name of the command, but rather to see what the general consensus of the idea would be. Regards, Tim ---- On Tue, 21 Jul 2015 17:48:37 +1000 Martti Kühne<mysatyre@gmail.com> wrote ----
Could you please try not to inadvertently run into a name conflict with the very project you're talking about? See [0].
cheers! mar77i
Other than that, you seem to believe there are many inofficial repositories, when in fact, there's mostly one. And that is the AUR, which is taylored to be serving pacman's -U functionality specifically. That in turn has nothing to do with pacman otherwise. You can build a fully functional and complete system using *official* sources and officially *inofficial* ones (the AUR), so I'm not sure why pacman should serve inoffical repositories with a tool, thereby wrongly making them appear official. Such an impression will be held by the average user of such a tool (as regularly happens on Ubuntu), making this a definite -1 from my side. cheers! mar77i
On 21/07/15 17:56, Martti Kühne wrote:
Other than that, you seem to believe there are many inofficial repositories, when in fact, there's mostly one. And that is the AUR, which is taylored to be serving pacman's -U functionality specifically. That in turn has nothing to do with pacman otherwise. You can build a fully functional and complete system using *official* sources and officially *inofficial* ones (the AUR), so I'm not sure why pacman should serve inoffical repositories with a tool, thereby wrongly making them appear official. Such an impression will be held by the average user of such a tool (as regularly happens on Ubuntu), making this a definite -1 from my side.
Well... https://wiki.archlinux.org/index.php/Unofficial_user_repositories There seems to be more than one (and the AUR is not a repository at all...). And the Arch official/unofficial distinction does not come into this - pacman development decisions are made for the benefit of pacman, not Arch (although these do generally align). Allan
On 21 July 2015 at 14:58, Tim Groeneveld <tim@timg.ws> wrote:
That .conf file would be downloaded, and then placed into /etc/pacman.d
Why not point to a package similar to 'pacman-mirrorlist' for that mirror, this way the file in /etc/pacman.d/ can be managed in the future by updates to that package in the repo it's adding? eg, # repo-add repo.example.com 1. Search for TXT record of repo.example.com == http://repo.example.com/any/example-mirrorlist.pkg.tar.gz 2. pacman -U the TXT RR 3. The mirrorlist file is now manage in an ongoing basis (assuming the package actually exists in the 3rd party repo) This is of course a roundabout way of just running `pacman -U http://repo.example.com/any/example-mirrorlist.pkg.tar.gz` which is the more KISS way IMHO, although I see how having the 'repo-add' command would look/feel more polished.
participants (4)
-
Allan McRae
-
Martti Kühne
-
Phillip Smith
-
Tim Groeneveld