rmarquis / pacaur Goto Github PK

Implement partial custumizepkg support as a first step towards #12.

Adding or removing a binary dependency would be taken into account thanks to makepkg. Full support (adding or removing AUR dependencies) needs issue #8 to be solved.

Pacman 4.0.0 adds a new -S --recursive operation to upgrade a full dep chain.

See if that make sense to add that feature to AUR packages too.

Allow package building parallelizing. That's probably hard to achieve, but could be an important feature to improve speedup.

AUR deps chains calculation would need to be rewritten to segment chains in individual, consistent heaps to avoid aur building breakage.

Implement custumizepkg support. Issue #8 must be solved to allow full support.

pacaur shoud be abe to view/edit .install scriptlet when provided by the package.

Evaluate if this is useful and subsequently add an optional option to enable/disable editing. Maybe even some command line to bypass defined behavior. Default behavior should be "disabled".

That way we don't have to sit there and wait for each package individually to press [Y] to install it.

Would be much easier to press [Y] one single time at the end.

See https://bbs.archlinux.org/viewtopic.php?pid=970758#p970758 and https://bbs.archlinux.org/viewtopic.php?pid=970761#p970761

Try to find a nice workaround on the pacaur side. This would be temporary until https://bugs.archlinux.org/task/16352 is fixed.

Although any unknown option is passed to pacman, --asdeps doesn't work as expected.
This happens because packages detected in pacaur input are explicitly installed, while the others are installed as dependencies.

To do: Find a fix/workaround to be able to install "explicitly" installed packages as dependencies.

--ignore flag doesn't take binary deps into account, although it works with binary packages (through pacman) and aur dependencies.

See if performance can be improved by using /dev/shm as temporary storage rather than on disk files, similarly to pbfetch. Could be useful with json info, or even with any downloaded files.

That's something I've wanted to do for a long time, but completely forgot about it.

When carchmagic switch is enabled ($CARCH compatibility), first level of dependency solving is done on the bash side rather than on the RPC interface. The simplistic solver included in pacaur does not support dependency version yet:

Real life exemple: cower-legacy requires pacman<4.

carchmagic: false

pacaur -S cower-legacy
:: Package(s) cower-legacy not found in repositories, trying AUR...
:: pacman is available in core

AUR Targets (1): cower-legacy

Proceed with installation? [Y/n] n

carchmagic: true

pacaur -S cower-legacy
:: Package(s) cower-legacy not found in repositories, trying AUR...

AUR Targets (1): cower-legacy

Proceed with installation? [Y/n] n

This does not apply to second and following dependencies level or when carchmagic switch is disabed, as those case are successfully handled by cower.

Real life example: Installing "pacaur" succeed as expected, as cower-git is the first level dependency while pacman<4 is the second.

carchmagic: true/false

 pac -S pacaur
:: Package(s) pacaur not found in repositories, trying AUR...
:: pacman is available in core
:: pacaur-2.4.3-1 is up to date -- reinstalling

AUR Targets (2): pacaur cower-legacy

Proceed with installation? [Y/n] n

Add dependency version support to the bash side (carchmagic enabled only). Looking at yaourt code might be useful. Both packer and pbfetch (and probably aurget) suffer from the same flaw as they use a similar simple dependency solver.

If i create the directory for building and put in in /etc/pacaur.conf it works fine as root but normal users get a permission denied error.

pacaur fails when makepkg detects a dependency conflict. This happens because --noconfirm is passed to makepkg by default to allow a fast workflow (14b11fc). However, as the default answer when a conflict arises is "no", makepkg fails.
Need to fix without losing fast workflow if possible.

Allow pacmanBin preferred choice in order to use tools such as pacman2aria/powerpill-light that allows parallel and segmented downloads.

See if one could use or adapt such a tool to pacaur easily, and allows to wrap a wrapper as pacman binary:

pacaur pacmanBin var -> pacman2aria2 -> pacman-color  

Pacman 4 will be released with an additional auxiliary tool, paccache. Replacing pacaur's cache handling code might prove to be more flexible, less prone to bugs while easing future pacaur maintenance.

On the contrary of AUR deps, binary deps aren't checked recursively. The user doesn't know what are the binary deps that are going to be installed.

User case:

pacaur -S packer
:: Package(s) packer not found in repositories, trying aur... 
:: jshon is available in community

AUR Targets (1): packer

Proceed with installation? [Y/n]

However, jshon depends on the binary pakage "jansson" that needs to be installed.

pac -S jshon
resolving dependencies...
looking for inter-conflicts...

Targets (2): jansson-2.1-1 [0.03 MB]  jshon-20110803-1 [0.01 MB]

Total Download Size:    0.04 MB
Total Installed Size:   0.13 MB

Proceed with installation? [Y/n]

The "repodeps" array needs to be checked recursively. Also, dependencies of a repo deps are always available in repo.

Add reinstall and outdated warning. Both rely on a RPC call to the AUR and might be combined for speed up.
Implement either with cower or jshon.

pacaur -Scc --noconfirm option isn't taken into account by pacman, and thus not implemented by pacaur for $PKGDEST directory.
However, it is possible to pass automatically a non-default option to pacman, ie:

yes | pacman -Scc

Let's see if it worth and reasonable to implement for pacman to speed up operation, and then implement it for aur packages in $PKGDEST.

See also https://bugs.archlinux.org/task/18279

From https://bbs.archlinux.org/viewtopic.php?pid=970549#p970549 :

with aurget, if i dl and build a devel package and skipped out on cleaning, i still have a complete dir with up to date src; now let some revisions/commits pass and i want to update the src and build again. aurget would redownload the PKGBUILD, etc ..., but keep the devel src, so that it would only need to sync up to the latest ones, not needing to redownload them all, then proceed to build it.

How can i get this in pacaur if it is implemented? And if not, could you do it, assuming you have interest in doing so?

Try to set the "clean" option to "false" in /etc/pacaur.conf. It should do the trick (at least for PKGBUILDs that follow VCS PKGBUILD guidelines). The drawback is that all packages are going to retain their cache... But if it is possible to only clear "normal" package and retain vcs packages cache, I believe that is a feature worth implementing. I'll see what I can do in this regard.

Support for su is broken since #4 has been fixed.

standard in must be a tty

The following code doesn't work with "su", although it does when sudo is installed.

yes | makepkg <option>
yes | runasroot $pacmanBin -U $cachedpkg ${pacopts[@]}

Find a nice way to make su working again alongside sudo, or drop support entirely.

Pacaur specific command set (-s, -i, -d, -m, -y, -k, -u) and pacman-like command set (-S, -Ss, -Si, -Sw, -Su, -Qu) can be mixed resulting in erratic behavior.

Includes a sanity check to avoid this mess. When detected, pacman-like command should take precedence over pacaur specific commands and pass the additional options to pacman.

Implement ignored warning, similarly to what pacman does with binary packages.

It is not possible to use $tmpDir (/tmp/pacaurtmp-$USER) as $buildDir.

Make it possible, and make it the default setting.

Interesting...

pacaur -Sua --devel
:: Starting AUR upgrade...
:: aurora-hg 20-1 
:: meat-git 20111019-1 
:: package-query-git 20111025-1 
:: packer 20111026-1 
:: partitionmanager-svn 1257912-1 
:: yaourt-git 20111025-1 
:: package-query-git-20111025-1 is up to date -- reinstalling
:: partitionmanager-svn-1257912-1 is up to date -- reinstalling
:: meat-git-20111019-1 is up to date -- reinstalling
:: packer-20111026-1 is up to date -- reinstalling
:: aurora-hg-20-1 is up to date -- reinstalling
:: yaourt-git-20111025-1 is up to date -- reinstalling

AUR Targets (7): package-query-git partitionmanager-svn meat-git packer aurora-hg yaourt-git cower-git

Proceed with installation? [Y/n] n

6 devel packges are detected, but cower-git (uninstalled) is added to the targets list.
See if that bug is related to conflict code, and solve that mess.

Expac calls are bottlenecked by I/O disk access. Using expac in a loop is thus suboptimal.
Replace all expac loops by a single expac call to speed up code.

pacaur doesn't take into account added/removed AUR dependencies when you modify the local pkgbuild. As it rely on makepkg, only added/removed binary dependencies are taken into account.

Use case: sometimes people want to remove deps + add --disable-xxx build-options for avoiding unwanted functionality, e.g. one of the example configs in customizepkg disables dbus-glib for a package etc. Or, to add deps and extra build-options for added functionality.

Check if the AUR deps are modified, compute the dependencies again and pull new PKGBUILD if necessary.

The ignored pkgs management needs to be improved when upgrading. This apply to:

• ignored package that are installed and that have aur dependencies.
• upgrade that pulls new dependencies that are ignored.
• installed packages that are ignored and that have an upgrade that pulls new dependencies.

Package install that have aur or binary deps that are ignored are correctly handled.

User case:

A1 is installed.
A2 is a new version that brings B1 and C1 as new dependencies.
D1 is installed and a new version D2 is available.

Actually, if B1/C1 is ignored, build of A2 will fail. If A1 is installed but Ignored (to prevent upgrade), the new deps B1/C1 are installed anyway.

Example:

pacaur -Sa clyde-git --ignore clyde-git
:: Package(s) clyde-git not found in repositories, trying aur...
:: lua-lzlib is available in community
:: luasocket is available in community
:: luafilesystem is available in community
:: luasec is available in community
:: clyde-git is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n] n

AUR Targets (1): lua-yajl-git

Proceed with installation? [Y/n] n

Improve Ignorepkg management, similarly to what pacman does:

pac -Qur
:: a 1-1 -> 2-1 
:: d 1-1 -> 2-1

pac -S a
resolving dependencies...
looking for inter-conflicts...

Targets (3): b-1-1 [0.00 MB]  c-1-1 [0.00 MB]  a-2-1 [0.00 MB]

Proceed with installation? [Y/n]

When b is ignored:

:: The following package cannot be upgraded due to unresolvable dependencies:
      a

Do you want to skip the above package for this upgrade? [y/N] n
error: failed to prepare transaction (could not satisfy dependencies)
:: a: requires b

When running pacaur with an empty $EDITOR you get a confusing error about permissions denied. A workaround is to define $EDITOR.

Example output:
pacaur -S pacman-color
:: Package(s) pacman-color not found in repositories, trying aur...

AUR Targets (1): pacman-color

Proceed with installation? [Y/n]

:: Edit pacman-color PKGBUILD? [Y/n]

/usr/bin/pacaur: line 206: /tmp/pacaurtmp-teh/pacman-color/PKGBUILD: Permission denied
:: Could not open pacman-color PKGBUILD

after pacaur install a aur package, I'd like to put the package 'foo_x86-64.pkg.tar.xz` into '/var/cache/pacman/pkg', so that I can keep a copy of packages. for example, when I copy a whole system from one computer to another, I can use /var/cache/pacman/pkg, instead of download all packages from Internet(which is slow).

something like this:

pacaur -S pacaur --cache 

# /etc/pacaur.conf
cache = false  # cache the package to /var/cache/pacman/pkg default is false

ABS pkgbuild could be improved by looking at the online pkgbuild instead of relying on the local ABS tree only. Also, pacaur could ask to update the ABS tree prior to any other operation. Looking at absent and aur-git might be a good idea, too.

$ pacaur -u

:: Starting AUR upgrade...
:: burp 1.6.3-0 -> 1.6.3-1
error: no targets specified (use -h for help)

As far as I remember, this problem didn't occur on previous versions (<2.2.0)

pacaur calls awk many time as an ugly workaround, ie:

pkgs=($(echo ${pkgs[@]} | awk -F "\n" '{print}' | awk -F " " '{print}'))

These should be replaced by cleaner, faster code. Try to remove all awk calls if possible.

pacaur -S, -Sw doesn't check if an aur package is already compiled and available in $PKGDEST, as pacman does for binary package in /var/cache/pacman/pkg. It download the taurball and compiles it again instead.

Athough ignored binary are correctly handled in normal operation, ignored binary deps fails when defined in pacman.conf

Without "IgnorePkg = jansson" in pacman.conf:

pac -S packer --ignore jansson
:: Package(s) packer not found in repositories, trying aur...
:: jshon is available in community
:: jansson is available in community
:: jansson dependency is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n] n
:: Unresolved dependency 'jansson'

With "IgnorePkg = jansson"

 pac -S packer
:: Package(s) packer not found in repositories, trying aur...
:: jshon is available in community
:: jansson is available in community
:: jansson dependency is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n] y

AUR Targets (1): packer

Proceed with installation? [Y/n] y
:: Edit packer PKGBUILD? [Y/n] n
:: Building packer package...
==> Determining latest git revision...
  -> Version found: 20110925
==> Making package: packer 20110925-1 (Sun Sep 25 16:30:13 CEST 2011)
==> Checking runtime dependencies...
==> Installing missing dependencies...
resolving dependencies...
warning: ignoring package jansson-2.2-1
warning: cannot resolve "jansson", a dependency of "jshon"
:: The following package cannot be upgraded due to unresolvable dependencies:
      jshon

Do you want to skip the above package for this upgrade? [y/N] looking for inter-conflicts...
 there is nothing to do
==> Missing Dependencies:
  -> jshon
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.
==> Determining latest git revision...
  -> Version found: 20110925
==> Making package: packer 20110925-1 (Sun Sep 25 16:30:13 CEST 2011)
==> Checking runtime dependencies...
==> Installing missing dependencies...
resolving dependencies...
warning: ignoring package jansson-2.2-1
warning: cannot resolve "jansson", a dependency of "jshon"
:: The following package cannot be upgraded due to unresolvable dependencies:
      jshon

Do you want to skip the above package for this upgrade? [y/N] looking for inter-conflicts...
 there is nothing to do
==> Missing Dependencies:
  -> jshon
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.
:: Build directory cleaned

pacaur should rely on --clean and --cleancache makepkg options instead of deleting the build subdirectory. Less code, cleaner code. I guess pacaur -c option should be kept to delete the PKGBUILD only.

pacaur uses the "yes" utility to confirm prompts instead of the --noconfirm option (in order to bypass the default "No" answer when a conflict arise). This leads to an prompt confirmation failure when the locale doesn't use "y" to confirm install or conflicting package replacement.

An easy workaround is to use in bashrc:

pacaur='LANG="en_US.UTF-8" pacaur'

Find the cleanest way to fix this in the code.

Binary dependencies are actually tracked by 2 differents variables:

• repodepspkgs, that tracks the primary binary dependencies given by cower
• repodepsdepspkgs, that tracks all recursive binary dependencies of the repodepspkgs var through expac

repodepsdepspkgs fiters duplicates and sort the deps lists, but on some case a dependencies might be listed in both variables. It also not possible to sort all deps alphabetically as there is a "break" between repodepspkgs and repodepsdepspkgs lists.

This is not an important task, as repodepspkgs and repodepsdepspkgs are used only to show the deps to the user. Dependencies installation are handled by makepkg.

Remove unecessary option in conf file. The less the better.

1. pacmanBin and color option might be removed. If pacman-color binary is detected, use color output.
2. Or only remove pacmanBin option. If color is true, use pacman-color binary and adapt the pacmanBin sanity check (might be preferable)

pacaur fails when trying to install a pkggroup that is ignored in pacman.conf. No error warning, just fails.
This happens because pacaur doesn't check package group with pacman/expac -Sg, but ping pacman -S --print instead (920f14a). This way allows to check one time instead of 2, which is faster, but it doesn't work when the target is set in IgnoreGroup in /etc/pacman.conf.
Try to find a way to fix this issue without losing the extra speed.

In pacman-like mode, add an option in config file to turn out prompting to edit PKGBUILDS. Similarly to aurget "edit_pkgbuilds" option, valid values would be "always", "never", or "prompt" (default).

This option does not concern non pacman-like commands.

See https://bbs.archlinux.org/viewtopic.php?id=125941

That bug probably can't be fixed in the pacaur side. See if it is possible to fix upstream, or use an ugly workaround in pacaur.

Bug reported upstream here: https://bugs.archlinux.org/task/27909

When installing packages from repositories and AUR at the same time, the current workflow is:

• pacman prompt
  -> install binary packages
• pacaur prompt
  -> install binary aur deps
  -> install aur pkgs and deps

It would be appreciable to change it to the following in order to speed up workflow:

• pacaur prompt
• pacman prompt (bypassed with --noconfirm)
  -> install binary packages
  -> install binary aur deps
  -> install aur pkgs and deps

Solving properly issue #4 first is probably a prerequisite.

The need of "LC_COLLATE=C makepkg" needed to implement #41 will become obsolete in the upcoming pacman 4.0.2.

See

• http://mailman.archlinux.org/pipermail/pacman-dev/2011-November/014762.html
• https://bugs.archlinux.org/task/27221

Remove the unnecessary code and close the issue when pacman 4.0.2 is released.

When using pacaur -m (build without installing), the build might fail if necessary deps aren't installed. See if "makepkg -sr" makes the trick here.

The pacaur and pacman-like command sets use different code. Some code is also necessary to handle the "selective update" feature.

Check if it is possible to remove some unnecessary code, or to merge both command sets code (ie, using "-Sua" for -u, "-Sa" for -y, "-Swa" for -m).

pacman does it. cower does it. pacaur must do it, too.

From https://aur.archlinux.org/packages.php?ID=49145

I am not sure if this can be considered a bug, but pacaur updated the
git version of a package, dated in the AUR as 2011-11-10, but in my
timezone (EST), it's 2011-11-09, so after I run the upgrade, pacaur
still prompts me to update because it doesn't take into account the
timezone difference. (The package is clipodder, by the way.) Can this
be fixed, or is this something that can't be helped?

Interesting "bug". Probably nothing that can be done in an simple and efficient way (apart from moving to far Eastern :]), but maybe someone can come up with a good idea?

pacaur -b can't build ABS package. Deps resolution is done for AUR pkgs only (via cower).

If cower doesn't return any deps, continue with makepkg. I guess this can be combined with #14 and maybe #8 to provide fully/partial automated resolution dependencies.

In some very rare case, bash dependency solving used when carchmagic is enabled might fail.
The (partial) bash solver implemented in pacaur handles case where $CARCH magic bash is used in first-level dependency, while subsequent dependency level are handle by cower.

This partial bash solver implementation might fail when

• the user install an AUR package that has an AUR dependency that uses $CARCH bash magic, and
• that AUR dependency isn't correctly handled by cower.

Also, there is no $CARCH bash magic check done on subsequent dependency level. If an error occurs, the user won't know what's happening.

This is a theoretical problem, as I'm yet to find a real user case (but I guess it surely exist in a practical point of view).
Find a real user case, and find a nice way to integer it in pacaur without complexifying too much the interface.