FS#34066 - [devtools] Correct operation requires the user not to be cautious about updates to devtools

Attached to Project: Arch Linux
Opened by Connor Behan (connorbehan) - Thursday, 28 February 2013, 04:18 GMT
Last edited by Andrea Scarpino (BaSh) - Monday, 13 May 2013, 09:04 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

If devtools is in a user's IgnorePkg variable, devtools will break due to the line: https://projects.archlinux.org/devtools.git/tree/mkarchroot.in#n75

The correct server to use is ascertained by running "pacman -Sddp extra/devtools". This uses pacman's own facilities to read mirrors and make sure they are valid. However, for an ignored package, there is no "target" and the command prints an empty string (and still succeeds). I strongly suspect this was the cause of: https://mailman.archlinux.org/pipermail/arch-general/2012-October/031862.html

Now I did not post a patch yet because there are several options for fixing this. If you would like me to write a patch, please state which one you prefer:

1. Have a list of a few common packages like devtools, pacman, linux, glibc, etc. If empty strings are encountered, devtools will try the next one before giving up.

2. Assume that the user keeps an abs tree and run "pacman --config /var/abs/core/pacman/pacman.conf -Sddp extra/devtools" in order to use a fresh config file.

3. Supply a fresh config file with devtools for this purpose.

4. Patch pacman so that "-Sp" returns a URL even when the package should be ignored. This sounds reasonable since IgnorePkg is mainly used to stop package downloads, not queries.

5. Do not try to be clever and include code that reads the mirrorlist from scratch.

6. Scan pacman.conf and warn the user about this instead of fixing it.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Monday, 13 May 2013, 09:04 GMT
Reason for closing:  Fixed
Additional comments about closing:  in 4.1.1
Comment by Pierre Schmitz (Pierre) - Thursday, 28 February 2013, 10:16 GMT
Well, it would be best if pacman had an api for querying these information.

For now I would say if you use your own fork of devtools you are on your own.
Comment by Connor Behan (connorbehan) - Thursday, 28 February 2013, 23:47 GMT
I'm not using a fork, but I might if this doesn't get fixed ;-). If other devs have similar thoughts, I'll write something for option 6.
Comment by Dave Reisner (falconindy) - Friday, 01 March 2013, 00:16 GMT
Better question -- why do you need to ignore devtools upgrades?
Comment by Dave Reisner (falconindy) - Friday, 01 March 2013, 00:17 GMT
Also,

> 3. Supply a fresh config file with devtools for this purpose.

We necessarily supply several.

$ pkgfile -l devtools | grep pacman
extra/devtools /usr/share/devtools/pacman-gnome-unstable.conf
extra/devtools /usr/share/devtools/pacman-kde-unstable.conf
extra/devtools /usr/share/devtools/pacman-multilib-staging.conf
extra/devtools /usr/share/devtools/pacman-multilib-testing.conf
extra/devtools /usr/share/devtools/pacman-multilib.conf
extra/devtools /usr/share/devtools/pacman-staging.conf
extra/devtools /usr/share/devtools/pacman-testing.conf
extra/devtools /usr/share/devtools/pacman-extra.conf

A patch to use one of these pristine files instead of the user's own config would be an easy solution.
Comment by Connor Behan (connorbehan) - Saturday, 02 March 2013, 05:30 GMT
On my systemd machine? I tried removing the namcap dependency since that was the only thing requiring me to have python3 permanently installed. For my purposes namcap only had to be installed in the chroot at the time of the build. But then again, I often do very stupid things. Like not realizing that pacman.conf files were already in devtools.

I sent this patch to arch-projects too.
Comment by Connor Behan (connorbehan) - Wednesday, 13 March 2013, 01:54 GMT
Since putting a mirrorlist somewhere other than /etc/pacman.d is allowed, the above would be trading one bug for another. Attaching a patch for pacman instead. If it's acceptable, it is probably too late for the upcoming release.

Loading...