Are you suggesting that when pacman downloads a cached file, it renames the file to prepend "$repo-" to it or something?

I'm not sure why this is an issue TBH, since having multiple repos offering non-unique package names seems to be broken by design. How do you know which repos's conflicting version you have installed?

If you are specifying which repo should be used for which package, via e.g. `pacman -S $repo/$pkg`, rather than simply relying on the most preferred repo, then I don't see why you would want to keep the inferior version offered by a different repo. Certainly, you cannot install both at the same time.

It could prepend "$repo/", i.e. create per-repo subdirectories.

If the repos are maintained by different people, I can check the packager info in pacman's output.

Keeping obsolete data is not a problem for a cache. Specifically, keeping versions from different repos would be useful in at least these cases:

- testing of a package from different repos
- if some tool using the ALPM library needs to download all packages from all repos to extract some information

An example of the second use case: https://github.com/lahwaacz/archweb_manpages The update script downloads all packages (which contain at least one man page) via pyalpm and extracts the man pages into a custom database. So far it hasn't been a problem because only well-maintained official Arch repos are involved, but it's definitely not robust.

Interesting perspective on a non-obvious use of pacman. :)

Though I'm still not sure why different repos should ever contain the same pkgname pkgver-pkgrel with different contents, I suppose it could happen...

The major issue I can think of, is that this would require packages which are moved from testing to core/extra/community, to be redownloaded. Currently we actually *rely* upon the idea that every pkgname pkgver-pkgrel should be unique.

I'm not sure what the right answer is, or indeed if there *is* a right answer.

If a package is moved from testing to core/extra/community, doesn't it keep the same pkgver-pkgrel? In that case, it would not have to be redownloaded until the user explicitly reinstalls.

Btw. I actually have a use case even for a custom repo containing the same package versions as the Arch repos. For example, I rebuild chromium with gtk2 instead of gtk3. The major advantage compared to chromium-gtk2 in the AUR is that I have groups=('modified') in the PKGBUILD and IgnoreGroup=modified in pacman.conf, so pacman -Syu actually notifies me whenever the Arch version is newer than mine :-)

1) It would keep the same pkgver-pkgrel, that's the problem as it won't be cached. If it makes sense to preserve packages from multiple repos, it certainly makes sense to preserve packages from testing. What happens if you temporarily disable testing and do `pacman -Suu`? What happens if you use extra-x86_64-build to build a package, and you've already downloaded its dependencies from testing?

I'm not sure how pacman would figure out which packages are supposed to be identical, and which ones are supposed to be rebuilds. Or if it should try. The solution that would cover every case, I guess, would be to check all subdirectories for exactly matching packages before downloading a repo-unique version to $repo/. But that might a case of "trying too hard".

2) Uh, that package should still be called chromium-gtk2. :p
And personally I would automate this by committing that to my local clone of the AUR package's PKGBUILD and doing a `git pull --rebase` to get AUR updates.

Whoever controls the repository can just include an appropriate prefix in the file names.

1) Another approach would be to allow the configuration of "repo groups" which would share the same cache subdirectory. Then the script which downloads all packages from all repos would configure a group for each repo to be robust and normally all Arch repos would be in the same group.

2) I agree that "chromium-gtk2" would be much more appropriate for the distribution among many people, but for personal use "chromium" is much better. It's the same as rebuilding packages from ABS locally [1], the custom repo is primarily just to distribute it from my workstation to my laptop (plus if somebody else wants to use it, I don't mind). Getting notifications from AUR would work only assuming that I'm not the maintainer and that the maintainer updates it soon after the Arch package.

3) Adding a prefix or suffix handles just the case when it happens on purpose. What would be the robust implementation of "download all packages from all repos and extract something" using (py)alpm?

[1] https://wiki.archlinux.org/index.php/Arch_Build_System#Preserve_modified_packages