Package Details: pacman-git 6.0.0.r5.g542910d6-1

Git Clone URL: https://aur.archlinux.org/pacman-git.git (read-only, click to copy)
Package Base: pacman-git
Description: A library-based package manager with dependency support
Upstream URL: https://www.archlinux.org/pacman/
Licenses: GPL
Conflicts: pacman
Provides: pacman
Submitter: None
Maintainer: eschwartz
Last Packager: eschwartz
Votes: 26
Popularity: 0.000902
First Submitted: 2009-09-07 17:32 (UTC)
Last Updated: 2021-06-30 23:18 (UTC)

Required by (223)

Sources (5)

Pinned Comments

eschwartz commented on 2019-05-31 04:58 (UTC)

For convenience I provide an unofficial repository containing prebuilt versions of this and a number of other AUR packages. See https://wiki.archlinux.org/index.php/Unofficial_user_repositories#eschwartz

The packages are signed using my [community] packaging key and are therefore trustworthy. :)

Latest Comments

eschwartz commented on 2021-06-02 06:00 (UTC)

fixed, this was overlooked in my initial #archlinuxarm discussion but is now excluded in their pacman update.

parkerlreed commented on 2021-05-27 20:43 (UTC)

fcf-protection is not valid for ARM targets. This is added to the ARM makepkg.conf which then makes compiles fail.

eschwartz commented on 2021-05-21 19:04 (UTC)

Fixed, see commit message. :(

solnce commented on 2021-05-21 13:23 (UTC)

The most recent PKGBUILD commit from today breaks the integrity checks for all four additional files. Needed to update the hashes before building.

eschwartz commented on 2021-02-14 03:37 (UTC)

The cargo cult of libdepends strikes again...

And if it did provide libalpm.so, it wouldn't help you since this is the git version which means any ABI-breaking changes won't bump the soname until release time, thus, depending on a soname version achieves precisely nothing.

I guess I could provide a (meaningless) libalpm.so, but... I've got no idea if these packages access APIs which have been changed in pacman 6.0.0alpha1, in which case it will hardly help.

katt commented on 2021-02-14 01:09 (UTC)

The fact this package doesn't provide libalpm.so like the [core] one does has now started causing issues.

Both arch-audit and arch-rebuild-order depends on it.

eschwartz commented on 2020-09-13 16:24 (UTC)

The changes are included. This package will never show a version number for maintenance-only backport releases that were never tagged from the master branch.

And thanks for testing it!

adventurer commented on 2020-09-13 16:11 (UTC)

@eschwartz: I'm using this package because of the new parallel downloads feature (which works very well!). However, I wonder, since pacman 5.2.2 has been available since 2020-07-14, if a new pacman-git version shouldn't be available as well. Or are the changes in 5.2.2 already included in this pacman-git version?

eschwartz commented on 2020-03-15 01:15 (UTC)

What is the purpose of providing libalpm.so? The purpose of providing pacman seems to be fairly evident, since anything that uses pacman depend on pacman. On the other hand, nothing in the official repos depends on libalpm.so (and I don't believe anything other than yay-git depends on it) -- what's the objective here?

And if it did provide libalpm.so, it wouldn't help you since this is the git version which means any ABI-breaking changes won't bump the soname until release time, thus, depending on a soname version achieves precisely nothing.

hugegameartgd commented on 2020-03-14 14:38 (UTC) (edited on 2020-03-14 14:49 (UTC) by hugegameartgd)

@eschwartz The official pacman from core provides libalpm.so (see https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/pacman ) so it would be better to change it to that combined with provides=("pacman=${pkgver%.*.*}").

Edit: here is the diff/patch:

diff --git a/PKGBUILD b/PKGBUILD
index bca53b8..d73a3ca 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -5,7 +5,7 @@
 # Contributor: Andres Perera <aepd87@gmail.com>

 pkgname=pacman-git
-pkgver=5.1.1.r221.g8f89e509
+pkgver=5.2.1.r53.g87b74fcd
 pkgrel=1
 pkgdesc="A library-based package manager with dependency support"
 arch=('i686' 'x86_64' 'arm' 'armv6h' 'armv7h' 'aarch64')
@@ -18,6 +18,7 @@ optdepends=('pacman-contrib: various helper utilities'
 makedepends=('git' 'asciidoc' 'meson')
 checkdepends=('python' 'fakechroot')
 provides=("pacman=${pkgver%.*.*}")
+provides+=('libalpm.so')
 conflicts=('pacman')
 backup=("etc/pacman.conf"
         "etc/makepkg.conf")

eschwartz commented on 2019-10-29 20:19 (UTC) (edited on 2019-10-29 20:21 (UTC) by eschwartz)

Why does pacman-git doesn't provide pacman 5.2

But it does, because

$ pacman -Qi pacman-git
[...]
Provides        : pacman=5.2.0

yay-git still fails because of libalpm.so line

So, 'libalpm.so' doesn't look like 'pacman' to me.

I'm unsure why it was added to the yay-git package, and I'll tell you right now that using sonames won't work the way AUR package maintainers expect -- the result will simply be that you cannot upgrade pacman until you uninstall yay, then pacman -Syu, then rebuild and reinstall yay. Using sonames makes it harder, not easier, to use the AUR.

(There is exactly one AUR helper where it helps, and that is aurutils which can rebuild yay-git without first uninstalling it in order to upgrade pacman.)

hugegameartgd commented on 2019-10-29 19:04 (UTC)

@rafaelff Thanks, pacman --version shows Pacman v5.2.0-6-gf37a - libalpm v12.0.0 and yay-git still fails because of libalpm.so line, maybe I should report it there. Editing yay-git PKGBUILD locally fixed it for me.

rafaelff commented on 2019-10-29 18:46 (UTC) (edited on 2019-10-29 18:47 (UTC) by rafaelff)

@hugegameartgd: That version is exactly what is in the PKGBUILD, but this is a VCS package so its version gets updated when building the package. Even if the pkgver doesn't show 5.2.0, it is updated with the pacman master branch. So it does provide latest state of this repository.

Regarding the error about libalpm, removing 'pacman' to install 'pacman-git' breaks the AUR helper dependency. Please build pacman-git without an AUR helper, as they depends on pacman. Follow https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_packages

hugegameartgd commented on 2019-10-29 18:41 (UTC)

yay shows version 5.1.1

[user@archlinux ~]$ yay -S --devel --timeupdate pacman-git
:: Checking for conflicts...
:: Checking for inner conflicts...

==> Package conflicts found:
 -> Installing pacman-git will remove: pacman

==> Conflicting packages will have to be confirmed manually

[Aur: 1]  pacman-git-5.1.1.r221.g8f89e509-1

and later when trying to replace pacman with pacman-git

:: pacman-git and pacman are in conflict. remove pacman? [y / n] y
Error: Could not prepare the operation (Can not fulfill dependencies)
:: Removing pacman violates dependency 'libalpm.so> = 12', needed by yay-git
[user @ archlinux ~] $

eschwartz commented on 2019-10-29 17:52 (UTC)

It does, check again.

hugegameartgd commented on 2019-10-29 17:40 (UTC)

Why does pacman-git doesn't provide pacman 5.2? It's already in the main repo.

brikler commented on 2019-10-25 07:56 (UTC) (edited on 2019-10-25 08:01 (UTC) by brikler)

i am not able to build because wrong reverence… a idea how to solve it?

pacman -Q gpgme
gpgme 1.13.1-1
../lib/libalpm/signing.c:177: error: undefined reference to 'gpgme_check_version_internal'
../lib/libalpm/signing.c:179: error: undefined reference to 'gpgme_set_locale'
../lib/libalpm/signing.c:181: error: undefined reference to 'gpgme_set_locale'
../lib/libalpm/signing.c:192: error: undefined reference to 'gpgme_engine_check_version'
../lib/libalpm/signing.c:196: error: undefined reference to 'gpgme_set_engine_info'
../lib/libalpm/signing.c:198: error: undefined reference to 'gpgme_get_engine_info'
../lib/libalpm/signing.c:207: error: undefined reference to 'gpgme_strerror'
../lib/libalpm/signing.c:235: error: undefined reference to 'gpgme_new'
../lib/libalpm/signing.c:254: error: undefined reference to 'gpgme_release'
../lib/libalpm/signing.c:240: error: undefined reference to 'gpgme_get_key'
../lib/libalpm/signing.c:249: error: undefined reference to 'gpgme_strerror'
../lib/libalpm/signing.c:251: error: undefined reference to 'gpgme_key_unref'
../lib/libalpm/signing.c:552: error: undefined reference to 'gpgme_key_unref'
../lib/libalpm/signing.c:276: error: undefined reference to 'gpgme_new'
../lib/libalpm/signing.c:293: error: undefined reference to 'gpgme_strerror'
../lib/libalpm/signing.c:295: error: undefined reference to 'gpgme_release'
../lib/libalpm/signing.c:326: error: undefined reference to 'gpgme_new'
../lib/libalpm/signing.c:418: error: undefined reference to 'gpgme_strerror'
../lib/libalpm/signing.c:421: error: undefined reference to 'gpgme_release'
../lib/libalpm/signing.c:329: error: undefined reference to 'gpgme_get_keylist_mode'
../lib/libalpm/signing.c:333: error: undefined reference to 'gpgme_set_keylist_mode'
../lib/libalpm/signing.c:338: error: undefined reference to 'gpgme_get_key'
../lib/libalpm/signing.c:421: error: undefined reference to 'gpgme_release'
../lib/libalpm/signing.c:446: error: undefined reference to 'gpgme_new'
../lib/libalpm/signing.c:453: error: undefined reference to 'gpgme_op_import_keys'
../lib/libalpm/signing.c:455: error: undefined reference to 'gpgme_op_import_result'
../lib/libalpm/signing.c:279: error: undefined reference to 'gpgme_get_keylist_mode'
../lib/libalpm/signing.c:281: error: undefined reference to 'gpgme_set_keylist_mode'
../lib/libalpm/signing.c:285: error: undefined reference to 'gpgme_get_key'
../lib/libalpm/signing.c:289: error: undefined reference to 'gpgme_key_unref'
../lib/libalpm/signing.c:289: error: undefined reference to 'gpgme_key_unref'
../lib/libalpm/signing.c:348: error: undefined reference to 'gpgme_get_key'
../lib/libalpm/signing.c:770: error: undefined reference to 'gpgme_data_release'
../lib/libalpm/signing.c:771: error: undefined reference to 'gpgme_data_release'
../lib/libalpm/signing.c:629: error: undefined reference to 'gpgme_data_new_from_stream'
../lib/libalpm/signing.c:642: error: undefined reference to 'gpgme_data_new_from_mem'
../lib/libalpm/signing.c:651: error: undefined reference to 'gpgme_op_verify'
../lib/libalpm/signing.c:653: error: undefined reference to 'gpgme_op_verify_result'
../lib/libalpm/signing.c:646: error: undefined reference to 'gpgme_data_new_from_stream'
collect2: Fehler: ld gab 1 als Ende-Status zurück

eschwartz commented on 2019-05-31 04:58 (UTC)

For convenience I provide an unofficial repository containing prebuilt versions of this and a number of other AUR packages. See https://wiki.archlinux.org/index.php/Unofficial_user_repositories#eschwartz

The packages are signed using my [community] packaging key and are therefore trustworthy. :)

eschwartz commented on 2018-05-13 02:26 (UTC)

Sure, and I got another wonderful surprise over the weekend because allan accepted my fix for the gcc8 warnings. :D

yan12125 commented on 2018-05-12 16:51 (UTC)

Hi, could you drop support-file-5.33-pie-executable.patch? It's landed as https://git.archlinux.org/pacman.git/commit/?id=03272ad57142a1c7dacf1d9933d52650d3936225

eschwartz commented on 2018-05-09 17:12 (UTC)

--enable-debug enables -Werror in addition to #define PACMAN_DEBUG

This causes issues because gcc8 has new warnings. I've been waiting to see if Allan can write a patch over the weekend that fixes these, in which case the issue will naturally disappear.

polygamma commented on 2018-05-09 16:58 (UTC) (edited on 2018-05-09 16:58 (UTC) by polygamma)

It is currently not possible to build the package. makepkg output:

cc1: all warnings being treated as errors
make[3]: *** [Makefile:825: libalpm_la-remove.lo] Error 1
make[2]: *** [Makefile:928: all-recursive] Error 1
make[1]: *** [Makefile:984: all-recursive] Error 1
make: *** [Makefile:893: all] Error 2

EndlessEden commented on 2018-04-23 01:53 (UTC) (edited on 2018-04-25 07:12 (UTC) by EndlessEden)

@Eschwartz - Fair enough. Thank you for all your work. - I wasnt aware that they were using package signing right now. Ill switch my repos to signed. thank you for that info as well.

(P.S. - Gosh those edits are so clean. Amazing work.)

eschwartz commented on 2018-04-22 18:42 (UTC)

I've asked on their IRC channel, and they were sort of vague about why they wanted the sync patch but admitted it "may not be needed as much anymore with most installations shipping with initramfs".

The stdin patch reverts https://git.archlinux.org/pacman.git/commit/?id=e374e6829cea3512f0b4a4069c5a6168f0f8d8a0 which we added to pacman for good reason, and they indicated that while some packages prompt the user in the install script to e.g. flash the u-boot images, their install scripts know how to handle lack of stdin. I see no reason to revert this, since the user can very well follow the fallback prompts and this "feature" is broken in many cases.

For the signature checking I was told "it's up to the user to initialize their keys". I have even less than zero interest in supporting this use case.

I'm uploading a new version which adds the necessary CARCH support and uses pacman.conf.arm configured with their repositories. This seems sufficient to me.

EndlessEden commented on 2018-04-22 18:22 (UTC) (edited on 2018-04-22 18:23 (UTC) by EndlessEden)

@Eschwartz - "Split contrib" Ahh, sorry for the confusion. - I was unaware of that, as its not something i have any interest in normally.

"Stock Configurations" - ^_^ makes sense, ty for clarifying.

"signature checking completely disabled" - While I do agree on that, it is the way their repositories are set up (https://archlinuxarm.org/packages/armv7h/pacman/files/pacman.conf). I don't know who currently maintaining packages, but I don't believe they are currently signed. Thats something I would ask Kevin Mihelich kevin@archlinuxarm.org about. But, I would recommend you did, as I am not very familiar with arch repos and packaging security. it's typically not my concern, as in, not a packager.

patches -

0001-Sychronize-filesystem.patch From what I can tell Sync was added to prevent data loss. As a precaution on slow-writing mediums(Or poor flash media) - As I was just raising compliance, in my GitHub version of this package and not focused on reasons for its use.(as its just harmless sync() before starting package operations.) In the patch-notes dating back to 2014, it states ###[Since many problems arise from improper flushing of the filesystem, particularly package installations followed by a reboot very shortly after, this will perform a sync() after installations and removals to ensure a consistent filesystem state after package operations.]###

0002-Revert-close-stdin-before-running-install-scripts.patch Specifically, on ArchlinuxArm, closing stdin can be an issue during install/remove scripts and some other functions. But again I am not a developer and this function seems harmless, although could potentially be an issue for security if done on the archlinux-x86 platforms as there is no cleanup process. As Taken from the notes.

[This reverts commit e374e6829cea3512f0b4a4069c5a6168f0f8d8a0.

Arch Linux ARM packages have use cases for this feature, such as prompting the user to flash a new kernel to a bare partition. Removing this feature will undoubtedly cause more problems than it intends to solve.]### - If you want me to ask I can ask them for clarification?

0003-Revert-alpm_run_chroot-always-connect-parent2child-p.patch - This is no longer required, as these changes have already occurred upstream. As such I've removed it.

eschwartz commented on 2018-04-22 03:31 (UTC)

Regarding contrib, the Arch package version did not "supply it as part of its package", the contrib stuff was simply included in the pacman codebase and therefore enabled. Current development versions have split it out again, which is why it is a separate package, but it hasn't been decided whether to make it mandatory...

Stock configurations won't work, they assume pacman can be run by any consumer and don't contain the necessary options... like configured repository names.

But these ARM changes look sort of fishy to me, why is signature checking completely disabled with references to something that was changed in arch, 6 years ago, why is libalpm patched to add some questionable feature and remove another one, why is makepkg.conf only modified in order to remove -mtune=generic?

EndlessEden commented on 2018-04-21 00:51 (UTC)

@Eschwartz: "Potentially incorrect what?" - Upstream changes that dont find their way back into the static configurations. (Which i experienced last year, when a option was not documented. Although, i cannot recall what it was, offhand). //// "There's a reason the repo package also provides its own non-stock configurations." - Im confused, why is that? //// "I'm unmotivated to support the arm pacman.conf" - i already have a local version of this package with all the patches, etc. converted. if you were interested (https://github.com/EndlessEden/pacman-all-git) //// "pacman-contrib is already ... why it should be a hard dependency" - The Arch Package Version, has supplied this as part of its package since commit "b41b136a3"@2013-04-04 / Inclusion of it just makes more sense to me. But this i think is personal. I apologize if my opinion seems inaccurate.

eschwartz commented on 2018-04-20 21:06 (UTC)

Potentially incorrect what? There's a reason the repo package also provides its own non-stock configurations.

I'm unmotivated to support the arm pacman.conf, but feel free to submit PRs here: https://github.com/eli-schwartz/pkgbuilds -- I won't hunt down the necessary conf files myself, for a system I don't use.

pacman-contrib is already an optdepends, I don't see why it should be a hard dependency especially given it would be a circular dependency.

EndlessEden commented on 2018-04-20 19:52 (UTC) (edited on 2018-04-20 19:55 (UTC) by EndlessEden)

I have a few questions... 1. This package already generates pacman.conf and makepkg.conf, why include it? (its only included in the Generic packages from arch-team, to be more CPU generic and include additional mirror info for x86_64) - Wouldnt it be much cleaner to just sed or patch the data in, rather than replace with potentially incorrect files.

  1. Since this is a git package, why not add additional support for non-x86 platforms(IE: Arm). Its not hard to merge their patches here.

  2. Since Pacman-contrib was merged into Pacman, wouldn't it be smarter to make Pacman-contrib-git a dependency or include it into your package?

timofonic commented on 2017-07-23 05:01 (UTC)

pactree is missing. Is it in pacman-contrib-git?

polyzen commented on 2016-10-11 12:39 (UTC) (edited on 2016-10-12 21:11 (UTC) by polyzen)

contrib/ was removed from pacman. Please update the pkgbuild so a pacman-contrib package can be added. Edit: https://aur.archlinux.org/packages/pacman-contrib-git Once there's a release, pacman-contrib will be available in the repos.

AWhetter commented on 2016-05-01 20:10 (UTC)

Please could we start patching /etc/pacman.conf to replace 'pacman' in the HoldPkg list with 'pacman-git'.

eworm commented on 2016-01-29 09:27 (UTC)

makepkg bails out with an error: ==> ERROR: pkgver is not allowed to contain colons, hyphens or whitespace. ==> ERROR: Could not download sources. Can we remove the colon, please?

Scimmia commented on 2016-01-05 18:46 (UTC)

pkgver is invalid.

abandonedaccount commented on 2014-10-11 16:23 (UTC)

pacman-db-upgrade broke packages whose 'files' (file) contains %BACKUP% for example %BACKUP% is right on the next line after %FILES% as if some kind of sorting happened. And this causes pacman -Qo and -Ql to not see any files and thus attempting to upgrade/downgrade those affected packages causes `exists in filesystem` for each file. This happened after I upgraded from commit d9cf14ff1d69ac8834b84015c7971f55ce77645b to commit(latest currently): 7ee01c86669327b2af63c8ed9390bcbf071cdac5 Ok someone(demize) just notified me of this: https://lists.archlinux.org/pipermail/pacman-dev/2014-October/019422.html but may be worth to know if someone else if about to update from this

abandonedaccount commented on 2014-09-07 19:47 (UTC)

that pacman-git bug is tracked here: https://bugs.archlinux.org/task/41862

abandonedaccount commented on 2014-09-07 18:06 (UTC)

Looks like noextract option inside PKGBUILD prevents that file from being softlinked into ${srcdir} and thus the need to use ${SRCDEST} to access it. As an example of this try chromium-dev package. Tested with: Pacman v4.1.2-406-g3e19-dirty - libalpm v8.0.2 Without noextract it is symlinked, with noextract it isn't.

rafaelff commented on 2013-04-01 07:26 (UTC)

Pacman 4.1.0 in [testing] since today.

graysky commented on 2013-03-31 19:42 (UTC)

@maggie: I believe Allan was targeting the Easter weekend for 4.1's release but likely to [testing]. I took a stab at a PKGBUILD for pacman-git that will work with the current 4.0.3 series: https://gist.github.com/graysky2/5281746 Dave - feel free to check my math :p

graysky commented on 2013-03-31 15:05 (UTC)

@j - That needs to be captured in the PKGBUILD somehow, versioned dependency or at the very least, a comment.

rafaelff commented on 2013-03-31 14:24 (UTC)

@graysky: May I guess? 1) This is AUR and a GIT PKGBUILD is development-based; 2) Once you install pacman-git, eventual PKGBUILD updates will require the current format, otherwise will fail; -- anyway, one just have to follow the migration task using Allan's pkg tarball and it is all done.

graysky commented on 2013-03-31 14:07 (UTC)

@dave - why would you post a PKGBUILD that depends on development software to the AUR if what the previous poster said is true?

rafaelff commented on 2013-03-31 12:43 (UTC)

@maggie: Are you trying to install this package with pacman 4.0.3 ? I had this problem too and @RunningDroid's answer helped me - you need 4.1.0rc installed to support urls from VCS, like GIT.

maggie commented on 2013-03-31 11:28 (UTC)

I get errors when building: ==> ERROR: pkgver is not allowed to contain colons, hyphens or whitespace. When I change the pkgver to remove the -32: ==> ERROR: There is no agent set up to handle git URLs. Check /etc/makepkg.conf.

maggie commented on 2013-03-31 11:01 (UTC)

@falconindy Can you please make this package build latest git rather than point to a static tarball? I do not know enough about it to do it myself. Your commands are different from standard git packages. Thank you.

RunningDroid commented on 2013-03-20 17:20 (UTC)

@josephgbr You should use one of the packages here to add the features you need to install pacman-git: http://allanmcrae.com/2013/03/pacman-4-1-0rc1/ @falconindy Can you add fakechroot as a checkdepends, enough tests fail without it that makepkg --check fails.

rafaelff commented on 2013-03-10 06:11 (UTC)

Can someone please point me out how to get over the current lack of GIT download agent for this package? I'm translating pacman and, therefore, willing to test the translations. I'm not normally a user of this package, so I'm not following changes here, but I understand and read about changes in download methods, and now it fails to build as expected. Please help me on this subject?

AlD commented on 2013-02-05 09:47 (UTC)

If you depend on http access: source=('git+http://projects.archlinux.org/git/pacman.git')

falconindy commented on 2012-12-02 13:55 (UTC)

Bleh, yeah. Fixed. Didn't want to clobber my existing clone when testing.

eworm commented on 2012-12-02 13:48 (UTC)

The repo is cloned to "pman", not "pacman". This is a typo, no?

falconindy commented on 2012-12-02 03:49 (UTC)

You're welcome. Please don't mark this out of date because the provides array is "wrong".

luolimao commented on 2012-12-02 03:47 (UTC)

Thanks for the update

luolimao commented on 2012-12-02 03:22 (UTC)

Please, as RetroX mentions, do add the version to the provides array

commented on 2011-10-18 00:05 (UTC)

Please change the "provides" option in the PKGBUILD for the pacman-git package to pacman=4.0.

falconindy commented on 2011-02-14 21:29 (UTC)

This isn't the place for such reports. Bring this to the bug tracker.

haagch commented on 2011-02-14 21:23 (UTC)

I have a problem. On 64 bit everything still works fine but on my 32 bit netbook I got a problem with installing or upgrading packages. "pacman -Suu --debug" ("pacman -S" too) gives http://aur.pastebin.com/1AEGeR4K I am pretty sure that I am not "out of memory"... Here the culprit got introduced: http://mailman.archlinux.org/pipermail/pacman-dev/2011-February/012402.html I don't know the code of pacman but there seems to be another reason that _alpm_pkghash_create(est_count * 2) returns NULL. Before that commit (03.02.2011) it worked fine, after the commit (08.02.2011) it doesn't, though I have not checked yet if _alpm_pkghash_create returned NULL before.

falconindy commented on 2011-01-15 14:36 (UTC)

Expected behavior. Please subscribe to pacman-dev if you are to be using this package.

commented on 2011-01-15 11:39 (UTC)

Some of the repos have only <repo-name>.db.tar.gz and no <repo-name>.db . pacman-git does not recognize those repos (see https://bbs.archlinux.org/viewtopic.php?pid=878575#p878575 ). Is this a bug or a design change in the pacman git version?

falconindy commented on 2011-01-03 14:40 (UTC)

Please make sure you run pacman-db-upgrade to update your local DB to the new pacman 3.5 format, otherwise your local DB will not be recognized properly.

falconindy commented on 2010-12-21 11:14 (UTC)

Well, there's a bigger issue with the db-upgrade script -- you put in a check to see if pacman is running. If this is intended to be run as part of an install scriptlet, there's going to be a lot of broken databases. Pulling it out for now.

Allan commented on 2010-12-21 04:27 (UTC)

I'm not sure the vercmp line in your install script works... comparing the version to 3.5.0 will not work for the git package. You might also want to add "--enable-git-version" to the configure line.