- Pacman-dev - lists.archlinux.org

[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

[pacman-dev] [Translation] [Chinese Simplified] update
by gan lu 10 Mar '08

10 Mar '08

A few improvement, thanks.

1 0

[pacman-dev] [patch] makepkg: add checksums and resume
by Ray Rashif 10 Mar '08

10 Mar '08

Hi Sorry for the interruption. As someone who makes use of this tool regularly, being able to include the hash-checks in one shot is helpful. Having an alias is alright but in some situations, not enough. I've now decided to simply include it in makepkg. For the benefit of $anybody here it is attached. If you don't know how to apply a patch and you're reading this (gasp!), do the following as root: patch -Np0 /usr/bin/makepkg /path/to/this/makepkg-checkresume.patch Summary: + variable GETINTEG + function insert_checksums + option -G,--getinteg eg. To rule the world at once with style we run "makepkg -Gic" It isn't that much warranted. However, it _can_ save some time. Something like this and Roman's download-resume patch would be good additions for the next update. If this has already been implemented in some other way, I'll be glad to see it soon. Now for a Q&A session. It appears that makepkg will be in $srcdir when it's called. However, I noticed the following under devel_update function: sed -i "s/^pkgver=[^ ]*/pkgver=$newpkgver/" ./$BUILDSCRIPT source $BUILDSCRIPT I didn't test this as I have no svn et al packages currently, but I see "source $BUILDSCRIPT" a lot. Just wondering whether we need to type in $startdir for every action on $BUILDSCRIPT. Anyway, I think some parts can directly make use of variables from makepkg.conf - messages for instance. I've reflected this to a little extent in this patch, like DB_CHECKSUMS. Do you guys think PKGBUILD-specific options would be useful? Say, something like --pkgver=$somever, so for trivial packages there'd be no need for further user intervention. You'd definitely have to rely on the beast called "sed" exclusively, though. Thanks and regards

3 3

[pacman-dev] Binary Database
by Dario Freddi 09 Mar '08

09 Mar '08

Hi everyone, I am writing this mail for a variety of reasons. First of all, some discussion in the forums, and then, because it's something that I've been thinking about for a long time. There have been many requests, AFAIK, for bringing pacman a binary database. Currently I'm writing a libalpm frontend, with some other guys (works in progress are @ KDEMod Forums), and we would really like to bring some improvements to Alpm, starting from its database. Every time this question arises (by doing a search through the forums), the answer is always "show us some code first". Well, nothing wrong with that, and unfortunately I have nothing to show now, but for a simple reason. Maybe I did not search well, but I still haven't found an answer to the following question: "Are pacman/alpm devs interested in having a binary database instead of the text based one?". If there is no interest, it would be useless to start coding. So I'd like to hear some voices/opinions. Then I will be more than happy to show some code. Cheers, Dario

2 1