[pacman-dev] [PATCH] Add script to update pacman database format
The pacman-db-upgrade script was added to detect old pacman database
formats and upgrade them.
Currently performs the merging of depends files into desc files in
the local database.
Signed-off-by: Allan McRae al...@archlinux.org
---
scripts/Makefile.am |7 +--
scripts/pacman-db-upgrade.sh.in | 34 ++
2 files changed, 39 insertions(+), 2 deletions(-)
create mode 100644 scripts/pacman-db-upgrade.sh.in
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index 78deb0b..7448691 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -10,14 +10,16 @@ OURSCRIPTS = \
pacman-optimize \
pkgdelta \
rankmirrors \
- repo-add
+ repo-add \
+ pacman-db-upgrade
EXTRA_DIST = \
makepkg.sh.in \
pacman-optimize.sh.in \
pkgdelta.sh.in \
rankmirrors.sh.in \
- repo-add.sh.in
+ repo-add.sh.in \
+ pacman-db-upgrade.sh.in
# Files that should be removed, but which Automake does not know.
MOSTLYCLEANFILES = $(bin_SCRIPTS) *.tmp
@@ -68,5 +70,6 @@ repo-add: $(srcdir)/repo-add.sh.in
repo-remove: $(srcdir)/repo-add.sh.in
rm -f repo-remove
$(LN_S) repo-add repo-remove
+pacman-db-update: $(srcdir)/pacman-db-update.sh.in
# vim:set ts=2 sw=2 noet:
diff --git a/scripts/pacman-db-upgrade.sh.in b/scripts/pacman-db-upgrade.sh.in
new file mode 100644
index 000..e28b1d2
--- /dev/null
+++ b/scripts/pacman-db-upgrade.sh.in
@@ -0,0 +1,34 @@
+...@bash_shell@ -e
+#
+# pacman-db-upgrade - upgrade the local pacman db to a newer format
+# @configure_input@
+#
+# Copyright (c) 2010 Pacman Development Team pacman-dev@archlinux.org
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+
+eval $(awk '/DBPath/ {print $1$2$3}' @sysconfdir@/pacman.conf)
+DBPath=${DBPath:-...@localstatedir@/lib/pacman/}/local
+
+# pacman-3.4 to 3.5 upgrade - merge depends into desc
+if [[ $(find $DBPath -name depends) ]]; then
+ echo == pacman-3.4 database format dectected - upgrading
+ for i in $DBPath/*; do
+ if [[ -f $i/depends ]]; then
+ cat $i/depends $i/desc
+ rm $i/depends
+ fi
+ done
+fi
--
1.7.3.3
Re: [pacman-dev] Misleading info when epoch is used
On 08.12.2010 00:40, Dan McGee wrote:
On Tue, Dec 7, 2010 at 5:40 PM, Allan McRae al...@archlinux.org wrote:
On 08/12/10 08:45, Sven-Hendrik Haase wrote:
On 07.12.2010 23:51, Nagy Gabor wrote:
$ sudo pacman -Su
warning: supertuxkart: local (0.6.2a-2) is newer than community
(0.7rc1-1)
What? First I thought that our vercmp code is buggy, but vercmp
binary worked as expected. Then I figured out that my local package has
epoch=1, but the epoch is unset on the community package (so this seems
to be a packager bug).
So the above message is simply misleading (probably this is not the
only one). It would be better to switch to a default version printing:
0.6.2a-2 [epoch=1], or 1#0.6.2a-2 etc.
In fact I don't like neither force nor epoch. Epoch is just a version
prefix, why don't we let the packager to workaround this (KISS)? We can
introduce a new separator (now we have one: '.'), for example '#', and
let the packager define his favourite pkgversion (maybe epoch in mind),
like 1#0.6.2a-2. Epoch just complicates code and leads to wtf
imho...
NG
I'm the packager of supertuxkart and I don't see what exactly went
wrong. I'm not using any funny options in the PKGBUILD. I realize that I
can fix your issue with options=(force) but is this an issue for
everyone or just you due to something you did?
This is not your fault. We are working on a better system than
options=('force') to a new system using epoch values. This is caused by
Nagy installing a package he built using the epoch method and then
attempting to update to a package without it.
He doesn't even have to build it for it to do this- it is the
automagic %FORCE% - %EPOCH% translation we started to do. Old
supertuxkart probably had a force (started being treated as epoch ==
1), new one doesn't (epoch == 0), you lose.
http://repos.archlinux.org/wsvn/community?op=compcompare[]=%2fsupertuxkart%2ftr...@25176compare[]=%2fsupertuxkart%2ftr...@34147
-Dan
Sorry, I am still confused. Does this mean I should act on this by
re-adding force or will you guys handle this in pacman somehow?
-- Sven-Hendrik
Re: [pacman-dev] Misleading info when epoch is used
On 08/12/10 22:31, Sven-Hendrik Haase wrote:
On 08.12.2010 00:40, Dan McGee wrote:
On Tue, Dec 7, 2010 at 5:40 PM, Allan McRaeal...@archlinux.org wrote:
On 08/12/10 08:45, Sven-Hendrik Haase wrote:
On 07.12.2010 23:51, Nagy Gabor wrote:
$ sudo pacman -Su
warning: supertuxkart: local (0.6.2a-2) is newer than community
(0.7rc1-1)
What? First I thought that our vercmp code is buggy, but vercmp
binary worked as expected. Then I figured out that my local package has
epoch=1, but the epoch is unset on the community package (so this seems
to be a packager bug).
So the above message is simply misleading (probably this is not the
only one). It would be better to switch to a default version printing:
0.6.2a-2 [epoch=1], or 1#0.6.2a-2 etc.
In fact I don't like neither force nor epoch. Epoch is just a version
prefix, why don't we let the packager to workaround this (KISS)? We can
introduce a new separator (now we have one: '.'), for example '#', and
let the packager define his favourite pkgversion (maybe epoch in mind),
like 1#0.6.2a-2. Epoch just complicates code and leads to wtf
imho...
NG
I'm the packager of supertuxkart and I don't see what exactly went
wrong. I'm not using any funny options in the PKGBUILD. I realize that I
can fix your issue with options=(force) but is this an issue for
everyone or just you due to something you did?
This is not your fault. We are working on a better system than
options=('force') to a new system using epoch values. This is caused by
Nagy installing a package he built using the epoch method and then
attempting to update to a package without it.
He doesn't even have to build it for it to do this- it is the
automagic %FORCE% - %EPOCH% translation we started to do. Old
supertuxkart probably had a force (started being treated as epoch ==
1), new one doesn't (epoch == 0), you lose.
http://repos.archlinux.org/wsvn/community?op=compcompare[]=%2fsupertuxkart%2ftr...@25176compare[]=%2fsupertuxkart%2ftr...@34147
-Dan
Sorry, I am still confused. Does this mean I should act on this by
re-adding force or will you guys handle this in pacman somehow?
It only affects the maybe four or five of us running pacman-git. I
think we can handle manually updating that package, so you are fine to
do nothing for the time being.
Allan
Re: [pacman-dev] [PATCH] Add script to update pacman database format
Allan McRae wrote: The pacman-db-upgrade script was added to detect old pacman database formats and upgrade them. Currently performs the merging of depends files into desc files in the local database. When is this expected to be released? I'll need to update perl-xyne-arch to handle this and it would be useful if I could insert a versioned dependency to prevent any breakage during the transition period. Am I correct in believing that the file format remains the same and that the merger is a simple insertion of the depends file into the desc file?
Re: [pacman-dev] [PATCH] Add script to update pacman database format
Allan McRae wrote: On 09/12/10 00:00, Xyne wrote: Allan McRae wrote: The pacman-db-upgrade script was added to detect old pacman database formats and upgrade them. Currently performs the merging of depends files into desc files in the local database. When is this expected to be released? I'll need to update perl-xyne-arch to handle this and it would be useful if I could insert a versioned dependency to prevent any breakage during the transition period. It has not hit the master git branch yet, but I would expect it to hit in the next major pacman release (3.5?) which is probably months away. Am I correct in believing that the file format remains the same and that the merger is a simple insertion of the depends file into the desc file? Correct - for the local db. The sync db format will not change (transition period is needed) but note that the sync dbs will not be extracted from their tarball any more. Allan Thanks for the warning.
Re: [pacman-dev] Misleading info when epoch is used
On Tue, Dec 7, 2010 at 11:44 PM, Dan McGee dpmc...@gmail.com wrote: On Tue, Dec 7, 2010 at 4:55 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote: In fact I don't like neither force nor epoch. Epoch is just a version prefix, why don't we let the packager to workaround this (KISS)? We can introduce a new separator (now we have one: '.'), for example '#', and let the packager define his favourite pkgversion (maybe epoch in mind), like 1#0.6.2a-2. Epoch just complicates code and leads to wtf imho... Well, of course a new separator is not necessary, packager can do everything with '.', e.g. he can use 1.0.6.2a-2. It is just more readable to the user (and the packager). The key here is that epoch is no more than a simple version prefix, and I think it is needless to introduce %EPOCH% database field etc. Because this is ugly as hell and it will result in 100+ bug reports and why is the version number off questions in the first year. KISS applies both ways- keep the code simple, but keep developers lives from becoming enveloped in the first level of hell, and this suggestion would unfortunately do that. :/ I am with Nagy until you convince me otherwise :) 'version number off' is exactly what happens in Nagy's example : warning: supertuxkart: local (0.6.2a-2) is newer than community (0.7rc1-1) The real version that pacman uses is epoch+version and thus the pkgver printed here is wrong and confusing. pkgver and epoch can be separate (in pkgbuild, db, etc..) but they need to be handled together. This includes being printed together. This raises then the question of implementation. It would definitely be simpler if there was just one field in pacman and in the db, and the result would be similar. This would also mean you could easily predict pacman behavior by just comparing pkgver using vercmp, which would be nice to have. Then we can wonder if we need a epoch field in the PKGBUILD or if packagers could just handle it manually by 'sanitizing' the pkgver, and adding an epoch version as a prefix is just one way to do that. But in any cases, Nagy's original report about misleading info is valid and I am sure it would trigger bug reports.
