use local repo instead of pacman -U

[rmarquis]

Redesign the internal design to use a local repo instead of using pacman -Ucalls.

Advantage might include:

• faster solving
• some dependency situation would be better handled
• simplification of the code, especially when handling split packages.

Cons:

• A lightly more complicate initial setup (might be an advantage to keep off the complete newbies that do not want to read anything).

See also #364 where this has been briefly discussed. This can be a nice workaround for handling mismatching data error.

[zyklotomic]

I am interested in contributing on this feature. I think using a local repo is a very good idea. What can I do to help?

[rmarquis]

Hi,

This is a rather big change. I don't plan to work on it in the near feature as I want to stabilize current code instead.

I believe most of the split package code, and the cache code that I implemented over the year would become unnecessary, or at least greatly reduced. I guess I'd throw away the whole MakePkgs() function and rebuild from the ground up. Should obviously done in a new branch, cannot be done step by step in master.

[AladW]

If someone wants to implement this, I highly recommend to use pacutils (in particular pacconf) to work with the pacman configuration. Without it, you'd have to rely on fragile adhoc filters and make explicit assumptions where repos are configured (i.e., no Include support), amongst other issues. It's been in the community repository for a while.

Re split packages, you can indeed throw out any custom code that handles that, since pacman takes care of it. That said, there's other drawbacks:

• Decide how to upgrade the local repo. With pacconf a "partial" -Syu, i.e. a full upgrade on the local repo only, can be done easily by dynamically generating the required pacman configuration.
• Checksum mismatches on rebuilding packages. Most of them can be avoided by having a second CacheDir that points to the local repo, but a "garbage collection" for -Sc (which searches for packages with the same name in cache folders that are -not- the local repository) may be useful. Again, pacutils makes latter task trivial.
• Stupid users who misuse the replaces field in their PKGBUILDs. The best I've come up with is manually parse the database, mangle the results with grep and paste, and specify it to pacman's --ignore option. Yeah.
• The requirement for the exact package name as required by repo-add, i.e. makepkg --packagelist isn't sufficient. You might think it is, but packages may have the same name but a different archive extension. Simple approach is to use some intermediary directory to point PKGDEST to (as makepkg has all required information), get the package names, and move them back into place. As a side benefit, if a package is rebuilt the old build can be kept via mv --backup.
• Instead of the above, you can use some automatic repo generation tool like repose. These tools are inherently more complex and prone to breakage.
• Repos must be generated with LANG=C, or they will break if pkgname or pkgver contains unicode characters.

All in all, even if you get some other benefits like pkgfile support, the amount of bugs and quirks makes it a pain to implement. Feel free to look at https://github.com/AladW/aurutils/blob/master/bin/aurbuild if still interested (ignoring the gpg and chroot stuff, which I doubt is interesting to support here), or just use it directly; I have no idea how it would intertwine with existing pacaur code, though.

[rmarquis]

Thanks a lot for your detailed input, much appreciated.

These tools are inherently more complex and prone to breakage.

Just to be sure, do you refer to "automatic repo generation tools" here (fe. repose)? I'd have thought these tools would actually provide a more robust implementation.

From what I read above, this feature requires a near complete redesign of the core code - at which point I wonder if it really worth the effort. I actually don't have the time to do this, but this might be implemented on the longer term.

[AladW]

Just to be sure, do you refer to "automatic repo generation tools" here (fe. repose)? I'd have thought these tools would actually provide a more robust implementation.

Yeah, they do cover more ground. But when something goes wrong, it's more involved to debug them, e.g. you're expected to not only submit backtraces but also a full copy of the local repository. Though some of them like repoctl wrap repo-add rather than use a custom implementation.

[rmarquis]

This isn't worth the effort, especially since using a local repo pretty much doesn't solve any issue in the single machine scenario that pacaur is designed for, but it does bring a whole set of drawbacks requiring workarounds. Closing.