- Pacman-dev - lists.archlinux.org

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-74-g35135c0
by Dan McGee 12 Mar '08

12 Mar '08

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 35135c0a0cbac592e72296c0ca64e9def0308942 (commit) via d060e31be3586ce27382f80eaed7a9edf2c86aeb (commit) via f56f7ff39102dab754573b0bc40dbceb5a8ec301 (commit) from 91b7f288fe65b96d4af64f6308b0e33b14ad85e0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 35135c0a0cbac592e72296c0ca64e9def0308942 Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Mon Mar 3 22:09:21 2008 +0100 Add -Rss option * -Rss removes all dependencies (including explicitly installed ones). * updated documentation * two pactest files added to test the difference between -Rs and -Rss Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> commit d060e31be3586ce27382f80eaed7a9edf2c86aeb Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Mon Mar 10 15:38:08 2008 +0100 Remove trans->targets Its implementation was quite broken: * add_loadtarget() might have silently filtered out some targets when replacing an older version. * This was used in sync.c to determine whether a target is implicit or not, which is incorrect behavior. Before this patch we silently removed user confirmed replacements; now we always warn on a replacement. * remove001.py behavior was quite odd in adding same target 5 times to the target list, we can change this behavior to be a failure. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> [Xav: changed remove001 pactest accordingly] Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> [Dan: rewrote commit message] Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f56f7ff39102dab754573b0bc40dbceb5a8ec301 Author: Roman Kyrylych <roman(a)archlinux.org> Date: Sun Feb 10 18:56:47 2008 +0200 makepkg: Support for resuming source downloads Download to *.part and remove the suffix if successful, thus md5sums will be checked only for complete files, and next time makepkg will resume downloading of partial file instead of complaining about invalid md5sums. Old DLAGENTS format is still supported. Late fix: Do not try to download %u first The output of grep was not suppressed, thus the output of get_downloadcmd was wrong because of extra line at the beginning that contained an unsubstituted (with %o and %u) entry from DLAGENTS. Signed-off-by: Roman Kyrylych <roman(a)archlinux.org> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: doc/makepkg.conf.5.txt | 3 +++ doc/pacman.8.txt | 2 +- etc/makepkg.conf.in | 10 +++++----- lib/libalpm/add.c | 2 +- lib/libalpm/alpm.h | 4 ++-- lib/libalpm/remove.c | 2 +- lib/libalpm/sync.c | 11 ++++------- lib/libalpm/trans.c | 18 ------------------ lib/libalpm/trans.h | 1 - pactest/tests/remove001.py | 5 ++--- pactest/tests/{remove049.py => remove050.py} | 13 +++++++------ pactest/tests/{remove049.py => remove051.py} | 13 +++++++------ scripts/makepkg.sh.in | 21 +++++++++++++++++++-- src/pacman/pacman.c | 9 +++++++-- 14 files changed, 59 insertions(+), 55 deletions(-) copy pactest/tests/{remove049.py => remove050.py} (51%) copy pactest/tests/{remove049.py => remove051.py} (50%) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [Translation][Chinese Simpilified] update
by gan lu 11 Mar '08

11 Mar '08

A little fine tuning, delete some unnessecary space before or after English word, thanks.

1 0

[pacman-dev] [PATCH] Add VerboseUpgradeInfo Option
by Justin Lampley 11 Mar '08

11 Mar '08

Attached is a patch to add an option that displays the old version of the package as well as size in column format for the upgrade operation. Another patch was submitted back in November for this, but it either got lost and buried in the list, or Dan just hated it :). When enabled, this is what the upgrade information looks like: Targets: Pkg Name New Version Old Version Size perl 5.10.0-2 5.8.8-9 15.37 MB cairo-perl 1.044-1 1.041-1 0.10 MB courier-authlib 0.60.2-2 0.60.2-1 0.17 MB dhcpcd 3.2.1-1 3.2.0-1 0.04 MB imagemagick 6.3.8.0-2 6.3.8.0-1 2.00 MB glib-perl 1.162-1 1.160-1 0.36 MB perl-event 1.09-3 1.09-2 0.09 MB perl-anyevent 2.8-6 2.8-5 0.02 MB perl-libintl-perl 1.16-3 1.16-2 1.11 MB perl-event-execflow 0.63-3 0.63-2 0.04 MB gtk2-perl 1.162-1 1.160-1 2.28 MB perl-gtk2-ex-formfactory 0.65-4 0.65-3 0.20 MB

5 9

[pacman-dev] [PATCH] Remove trans->targets
by Nagy Gabor 11 Mar '08

11 Mar '08

Hi! Patch attached. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

3 3

[pacman-dev] [PATCH] New sync1007.py pactest
by Nagy Gabor 11 Mar '08

11 Mar '08

From 9274e45ad97cce0749e23340cf51d8a3de0935b9 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Tue, 29 Jan 2008 13:43:08 +0100 Subject: [PATCH] New sync1007.py pactest This pactest shows that checkdeps can be fooled when a package exists in multiple repos. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- pactest/tests/sync1007.py | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 pactest/tests/sync1007.py diff --git a/pactest/tests/sync1007.py b/pactest/tests/sync1007.py new file mode 100644 index 0000000..4245142 --- /dev/null +++ b/pactest/tests/sync1007.py @@ -0,0 +1,18 @@ +self.description = "Conflicting package names in sync repos (checkdeps is fooled)" + +sp1 = pmpkg("pkg1") +sp1.depends = [ "pkg2=1.0" ] +self.addpkg2db("community", sp1) + +sp2 = pmpkg("pkg2", "1.1-1") +self.addpkg2db("testing", sp2) + +sp3 = pmpkg("pkg2", "1.0-1") +self.addpkg2db("extra", sp3) + +self.args = "-S pkg1 pkg2" + +self.addrule("PACMAN_RETCODE=0") +self.addrule("PKG_EXIST=pkg1") +self.addrule("PKG_EXIST=pkg2") +self.addrule("PKG_VERSION=pkg2|1.0-1") -- 1.5.3.8

3 2

[pacman-dev] [PATCH] Autoversion deps upon package creation in makepkg
by Darwin Bautista 11 Mar '08

11 Mar '08

Hi all, Attached is a patch to add "autoversion of dependencies" in makepkg. I think the usage of the term "autoversion" is a little vague but I can't of any other term. Anyway, autoversioning will save package maintainers a lot of time in adding and bumping the minimum required versions of a certain package's dependencies directly in the PKGBUILD. Of course, this autoversioning can be overridden by directly specifying the minimum/maximum (if ever)/exact version of a dep. Autoversioning can be disabled by using these opts: '-v' or '--nodepsver'. I've seen quite a lot of packages (extra, community) which have "out-dated" or wrong minimum versions of the deps. For instance, I've seen a package (which I can't remember) of a KDE app built against KDE 3.5.8 yet the specified minimum version is 3.5.7 (or older?). This can help prevent bugs resulting from this seemingly subtle issue. -- Darwin M. Bautista BS Electronics and Communications Engineering University of the Philippines Diliman http://www.darwin.uk.to University of the Philippines Linux Users' Group http://www.uplug.org

6 11

[pacman-dev] [PATCH] New --nonew option
by Nagy Gabor 11 Mar '08

11 Mar '08

See the attachment for patch. Other recommendations for option name and English language fixes are welcome :-P ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

6 21

[pacman-dev] [PATCH] Show options in pacman.conf (commented out)
by Nagy Gabor 11 Mar '08

11 Mar '08

Patch attached. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

2 1

[pacman-dev] [PATCH] Fix FS#8905 (-Sp as non-root)
by Nagy Gabor 10 Mar '08

10 Mar '08

From 80e66dda0239c04e75cda0771bd4627921aa098e Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Sat, 8 Mar 2008 18:35:44 +0100 Subject: [PATCH] Fix FS#8905 (-Sp as non-root) This patch is quite ugly, but solves the issue without API change. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/trans.c | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/lib/libalpm/trans.c b/lib/libalpm/trans.c index 52dbe7a..79a33f0 100644 --- a/lib/libalpm/trans.c +++ b/lib/libalpm/trans.c @@ -72,9 +72,11 @@ int SYMEXPORT alpm_trans_init(pmtranstype_t type, pmtransflag_t flags, ASSERT(handle->trans == NULL, RET_ERR(PM_ERR_TRANS_NOT_NULL, -1)); /* lock db */ - handle->lckfd = _alpm_lckmk(); - if(handle->lckfd == -1) { - RET_ERR(PM_ERR_HANDLE_LOCK, -1); + if(!(type == PM_TRANS_TYPE_SYNC && flags & PM_TRANS_FLAG_PRINTURIS)) { + handle->lckfd = _alpm_lckmk(); + if(handle->lckfd == -1) { + RET_ERR(PM_ERR_HANDLE_LOCK, -1); + } } handle->trans = _alpm_trans_new(); @@ -190,6 +192,7 @@ int SYMEXPORT alpm_trans_interrupt() int SYMEXPORT alpm_trans_release() { pmtrans_t *trans; + int nolock; ALPM_LOG_FUNC; @@ -197,6 +200,8 @@ int SYMEXPORT alpm_trans_release() ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1)); trans = handle->trans; + nolock = (trans->type == PM_TRANS_TYPE_SYNC) && (trans->flags & PM_TRANS_FLAG_PRINTURIS); + ASSERT(trans != NULL, RET_ERR(PM_ERR_TRANS_NULL, -1)); ASSERT(trans->state != STATE_IDLE, RET_ERR(PM_ERR_TRANS_NULL, -1)); @@ -204,6 +209,9 @@ int SYMEXPORT alpm_trans_release() handle->trans = NULL; /* unlock db */ + if(nolock) { + return(0); + } if(handle->lckfd != -1) { close(handle->lckfd); handle->lckfd = -1; -- 1.5.3.8

2 6

[pacman-dev] Re: Binary Database
by Dario Freddi 10 Mar '08

10 Mar '08

Hi Xavier, Sorry if I didn't hit you back immediately, but I wanted to read every discussion and make up my mind about the various proposals. So, let's go: I think we are more interested in trying to improve the current text based > one rather than switching to a binary database, at least as a first step. > For example, for the sync db, we could directly read from the archive : > http://bugs.archlinux.org/task/8586 > > Glad to hear. About the first one, I'm not a tar guru, and I don't know about how fast things could be if we read things from archive to memory. I've seen there is already some code for it, but benchmarks in real use cases would be better. What I fear is that reading too many times from a tar'ed archive could be somehow counterproductive (again, I could be completely wrong on that). I think that could be possible, if it's really worth it, but I don't have enough knowledge on this argument to say if that would be useful. I'd be glad to hear other voices. A second point of interest is unifying the format of the meta-info files inside the package (.PKGINFO) and the ones inside the database (depends / desc). Having just one format would simplify the code. We could also reduce the number of files in the sync and local database by merging them, which would reduce the impact of fragmentation and slow filesystems. http://www.archlinux.org/pipermail/pacman-dev/2007-June/008601.html This would surely be a plus, by now there is a real mess in the packages dirs, and it's useless, code-consuming and confusing to have different formats. Also, I propose to keep scriptlets in the Database. I clear my cache a lot of times for the sake of disk space, and whenever I try to remove a package, the remove scriptlet is not found. That could be harmful. It wouldn't be a lot of space. Just a random thought anyway. Otherwise, if we want to experiment with different backends, it would > probably be a good idea to try abstracting the backend code, so that we would > have all specific backend code in the same place, and have the possibility to > easily switch between several ones. That was also discussed ages ago, in the > same link as above : > http://www.archlinux.org/pipermail/pacman-dev/2006-March/005702.html > > This is *the* point. Everything we're saying is useless if we don't abstract things first. If we keep a "dirty" implementation, where backend code is mixed with database files parsing, porting improvements is a royal pain in that place. If we could create a set of functions that take care of giving out strings or files to parse to the current db functions in alpm, then changing the current backend, using multiple backend, have a CHOICE in backend choosing (imagine that! the end of the mother of all discussion in Arch Linux), it would be surely easier. Why don't we simply start from this? Let's make alpm a real library, let's abstract code, and let's create a dbbackend set of functions. If we study the code closely, and we want to do this (a bit boring) part, I can only imagine how many benefits we could take from this. I have nothing against the text-based database, but if we can "split" the backend part, it could have a lot of great benefits too. What do you think about that? More recently, there was an attempt of a sqlite backend : > http://www.archlinux.org/pipermail/pacman-dev/2008-January/011011.html > As you can see, this raises several problems of migrating the current code > base. And then there is also the problem of migrating the databases. > > Yeah, and that demostrates what I said in the last paragraph. Anyway, even if a bit OT, I think there could be a better solution than SQLite. Amarok with large (3000+) collection anyone? It takes ages to create collections, switching to MySQL makes things a lot faster. I'm not a SQLite guru again, but I have heard many voices saying that it's not so fast as it seems, especially in case it has a lot of entries (and that would be pacman's case). I'd like to hear someone competent (clarification : Competent doesn't mean "OMG text based sucks go SQLite because I was told it is faster" trolls, I mean arguments, benchmarks, and maybe a pair of lines of code that show how SQLite can handle a large DB). Well, I hope that throwing out some random ideas about the backend that were > discussed here wasn't too confusing. > But I think there is definitively an interest for improving the backend in > > No, that wasn't confusing at all :) I'm glad to hear that pacman developers know the current situation and want to do something about it. Well, voices don't always tell the truth, I expected a completely different answer here. I would be glad if we could come out with a plan and make things better, from us (me and other 2-3 people), there is a real interest in making alpm even better. Sorry for the long mail Cheers, Dario one way or another. > >

4 3