- Pacman-dev - lists.archlinux.org

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 27 Mar '08

27 Mar '08

sorry, I think alpm is totally shit was I don't think alpm is totally shit but I think you got that ^^ Dario

1 0

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 27 Mar '08

27 Mar '08

> > Well, I am not sure why you felt offended, Dan didn't mean it that way. > I'm not offended, I just feared that libalpm could disappear and all my efforts wasted. > What you did is indeed great, that would be the first real frontend > using libalpm. (well there is also gfpm using frugalware's libpacman, > but I don't think anyone really ported it to libalpm, at least it's not > uptodate). > Thanks a lot :) > But actually, that's the point, you are the only one, while there are > countless of others tools simply calling pacman, or parsing the stuff > themselves. > Exactly. This is the point. Experience teaches me one thing: people stick to habits. I think the only reason I developed Shaman this way is because I'm new to Arch, and alpm already existed. If Shaman previously used pacman and worked, I don't think I'd have taken the risk to port it to alpm. Or maybe, people still fear libalpm. Maybe they don't even know what it does, why it exists. Maybe they think it's a bit harder, well it is. But there is a huge difference. > Still, your project should give us a better idea about the quality and > usefulness of libalpm, and I hope that you will have concrete > suggestions for improving libalpm and making it more friendly to use :) That's why I showed you the link here. It was not a "oh, look, I'm so good", because I consider myself a really worse coder than the ones who develop pacman/alpm, and I'm speaking for real. I'm not talking about who can code better, I'm talking about ideas, and not coding. Sorry to say that, but Xavier, it was you who answered my mail. It was you who answered Lukas when he asked about alpm version. It is you that says that doors are open, and I really appreciate that. The point is that, even here, you're the only one. Because nobody else replied to that mail (or at least, replied to the point of that mail) but you. I don't pretend to be the solution of all the problems, and maybe some of my ideas are wrong, but developing Shaman helped me seeing a lot of flaws in alpm. A lot of unsafe behaviours. And this doesn't mean that I think alpm is totally shit. Do you think I'd have developed something upon pure shit? I'm not so masochist. Ok, sometimes I said it was, but it was frustration that made me speak. And I DO think that libalpm is worth the effort. Shaman is the living demostration that alpm works, that alpm is useful, both to developers and users, even if it has some design flaws. And I don't want it to die, because it doesn't have to. Alpm is more stable/efficient than apt/dpkg in my opinion, even if some bad choices in DB handling make it slower in searching and loading the database, but I've seen nothing handling package processing that fast, and that's the reason why I bet on Shaman, and I'd still make the same choice now. But I do believe that libalpm can be even faster. That something can be improved to make it even better. And that should be the question and the direction, being honest on ourself. And not listening to trolls who just say some banal/stupid stuff about SQLite and such, not saying "complicated and not worth it" when you don't even know what that thing could mean. I hope that was a bit clearer. Cheers Dario

1 0

Re: [pacman-dev] Libalpm direction and usage by others
by Dario Freddi 27 Mar '08

27 Mar '08

> > It is clear to us on the list that no one has really latched on to > using libalpm. Don't agree > To be honest, I don't blame anyone for this, as the > interface seems to have been drawn at a bad level, and calling things > like alpm_trans_commit() after 6 other functions and setting flags > right just isn't intuitive. > Agreed. > So, what does this lead us to? > 1. Document the existing interface better. Although it isn't perfect, > we aren't going to get frontend clients without documentation. As all > of us working on the one client that does use libalpm (pacman) have > clearly not felt a need for further documentation, this is really > going to have to be spearheaded by someone outside of our current > "normal" developers. Anyone want to step up? > Stop on that. When I started my work, I had only this (http://code.toofishes.net/pacman/doc/index.html) and the code. You know what? That was enough, and I didn't EVER complain about it. A competent programmer knows that, even if he had the best documentation around, sooner or later he will have to see the code to understand how things **really** work out. Sure, an improvement could be good, but don't forget that something is already out there. > 2. Frontend developers need to speak up and get ideas on this list. I > constantly see rhetoric like the above, where people say the current > API is not very good, but they have not done a damn thing to change > it. We can't read minds here, and we also aren't going to just change > things on our own. So speak up people! If we get some good discussion > going, we could really make changes to the API to make it usable. > I once sent a mail, I proposed some ideas, I got one (1) answer, and... what? I proposed to abstract the backend, some real things, I'm writing a whole paper on that, I'm ready to show you something REAL, some real ideas, some people who really want to do that but... where is the list? Why just shining answered to my mail? Why didn't anybody else step up and said: "Ok good" or "No, sucks". You wanna see some code? Some efforts? Is that one enough? http://shaman.iskrembilen.com/trac.cgi/wiki I wrapped libalpm around a C++ class and guess what? It works. It still has issues, but shaman works, and while I'm writing, a lot of people are using it, even if I still haven't put it on Arch bbs, since I want it to reach a real beta stage (where beta means usable, feature full, with some minor stuff, something we've almost achieved). Will somebody listen to that now? Will somebody say that alpm, library or not, needs improvements and not in the code, in the basic ideas around it? Will somebody finally admit that it's time to hear other voices? In my opinion, simplicity is also making life easier. Having a choice between db frontends is simple, since everyone can write its backend, and it gives the user freedom to use whatever it wants. > 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking > "but that would be a step backwards!". Would it? I can tell you this- > the pacman 2.9.8 codebase was about half the size of the current > monster, and we have a lot of crazy design issues going on. Instead of > trying to write a pacman library, why not just implement a friendly > frontend, command-line interface, which is a bit more Unix-y? For > example, monotone has its "automate" command (I haven't looked at this > in some time, so let me know if I am wrong) that is designed to be > used by other clients as machine-parseable. git is based around this > concept as well- look at all the low level tools like rev-parse, etc. > 4. Switch to something like python. I'm resistant to this idea. > Although I think scripting languages like this have great benefits, I > don't think pacman needs most of them. Having a package manager that > always works is important to me, and part of me just thinks a > low-level compiled language is the right thing for a system tool. > Python or not, don't even think on that. First of all, all our efforts into shaman would be a waste. Secondly, you close every door through a different frontend than pacman, and I don't really think this is really the Arch way. > Of the four options above, I have been pushing 1 and/or 2 for a long > time. However, I am starting to lean toward option 3. I'd love to hear > your thoughts on this. > This is my thought. Out there, a lot of people have great ideas about pacman/alpm, but nobody here ever seemed to have listened to them. You asked for some code, I brought you Shaman. I'm ready to get up with some well documented ideas, but I don't know if there is the right attitude to accept other point of views. And I'm not talking about the SQLite stuff - I hate SQLite, and it sucks for a package manager. But honestly... would you give alpm the fault for all those void*s, for all that useless package structs, and whatever else? There is someone who latched over libalpm, and it's me. I believed in it, even a lot of stuff was wrong, and the result is Shaman. You can say you don't like it, ok, that's fine. What you can't say is that it is a real step forward compared to gtkpacman & friends, that used pacman instead (I'm not saying they're bad, I'm just showing the difference in wrapping pacman and libalpm, gtkpacman still remains a piece of software IMHO) > -Dan > Didn't mean to offend anyone, sorry if I did. Cheers Dario

2 1

[pacman-dev] PacTrac was: Re: [arch-general] [arch-dev-public] ArchISO FTP Installer - Testers Needed
by Roman Kyrylych 27 Mar '08

27 Mar '08

2008/3/27, Christos Nouskas <nouskas(a)gmail.com>: > Damir Perisa wrote: > > i have a no-optical-drive laptop (non-macs are not able to boot from > > firewire cdroms) and usually i prepare a image to put on a > > memory-stick to boot from [1]. since this setting (no cdrom) are > > getting more common and having a live-linux-system on a usb-key is > > getting interesting i'm wondering if we should provide also a > > partition image[2] for such use? > > > I've been using FaunOS (http://www.faunos.com/) for a couple of months > now, and my opinion can only be described as excellent. It's a live > archlinux system focused on booting from detachable usb media, fits in a > 1GB stick, does a wonderful job in hardware detection (I tested it in 3 > different machines), saves all changes back to the usb stick, suspends to > usb and it's FAAAAAST! Wherever I can't take my arch-laptop, I take my > usb stick! Hm, it has an interesting frontend to pacman - PacTrac. I especially like the dependency tree: http://www.faunos.com/images/ver-0.5.4-stable/pactrac-install.png -- Roman Kyrylych (Роман Кирилич)

7 10

Re: [pacman-dev] [arch-general] lzma compression tests
by Dan McGee 25 Mar '08

25 Mar '08

CCing to pacman-dev. On Mon, Mar 24, 2008 at 3:25 PM, Jan de Groot <jan(a)jgc.homeip.net> wrote: > > On Mon, 2008-03-24 at 14:43 -0500, Dan McGee wrote: > > On Mon, Mar 24, 2008 at 2:24 PM, Mark Constable <markc(a)renta.net> wrote: > > > FWIW, possibly worth considering adding lzma to pacman... > > > > > > http://www.kdedevelopers.org/node/3326 > > > > > > --markc > > > > Interesting. You may want ot take this to the pacman-dev ML. A good > > "real-world" look might be grabbing the openoffice package and > > uncompressing it to a folder, and then run the following tests: > > > > bsdtar czf package (gzip) > > bsdtar cjf package (bzip2) > > <lzma creation of package> > > > > and then the similar unzip costs, along with the size of the original > > folder structure (unzipped package) vs. their zipped counterparts. > > > > -Dan > > > > I tested with OpenOffice.org, here are the results. Note that I had to > use a weird construction to compress lzma files, as tar has no native > support yet (1.19.90 has official lzma support I read on some debian > mailinglist). > > Compression times take a huge increase in time, but in case of > openoffice, I think 30 seconds extra compression time will save on much > more upload time, as the resulting package would be 20MB smaller. > For the end user, it depends on their connection. Most users will have > <10Mb/s connections and will see a positive change in installation > speed: 10 seconds extra for extraction, 20 seconds less for downloading > the package. > > [jan@server ~]$ time bsdtar czf oo.tar.gz oo/ > real 0m24.244s > user 0m23.882s > sys 0m0.360s > > [jan@server ~]$ time bsdtar cjf oo.tar.bz2 oo/ > real 0m55.812s > user 0m55.310s > sys 0m0.377s > > [jan@server ~]$ time tar c oo | lzma -2 > oo.tar.lzma > real 0m55.070s > user 0m54.583s > sys 0m0.740s > > [jan@server ~]$ time tar c oo | lzma -1 > oo.tar.lzma1 > real 0m38.995s > user 0m38.737s > sys 0m0.503s > > [jan@server ~]$ du -h oo.tar.* > 108M oo.tar.bz2 > 115M oo.tar.gz > 95M oo.tar.lzma > 101M oo.tar.lzma1 > > [jan@server u]$ time tar zxf ../oo.tar.gz > real 0m3.570s > user 0m3.383s > sys 0m0.967s > > [jan@server u]$ time tar jxf ../oo.tar.bz2 > real 0m19.431s > user 0m17.826s > sys 0m1.367s > > [jan@server u]$ time tar --use-compress-program=lzma -xf ../oo.tar.lzma > real 0m13.211s > user 0m12.306s > sys 0m1.117s > (the lzma1 archive gives equal timings) Did you try with bsdtar on the extraction as well? That may make a difference over (gnu)tar. Should be: time bsdtar xf ../oo.tar.gz time bsdtar xf ../oo.tar.bz2 time bsdtar --use-compress-program=lzma -xf ../oo.tar.lzma -Dan

3 2

[pacman-dev] bug during package upgrade?
by Roman Kyrylych 24 Mar '08

24 Mar '08

Hi! Here's Tobias' pacman.log. Notice that klibc-kbd is not installed at all, though the newest mkinitcpio depends on it. The line [2008-03-21 19:57] installed klibc-kbd (1.15.20080312-4) at the bottom is from manual installation. ---------- Forwarded message ---------- From: Tobias Powalowski <t.powa(a)gmx.de> Date: 22 бер. 2008 00:14 Subject: big upgrade To: Roman Kyrylych <roman.kyrylych(a)gmail.com> -- Roman Kyrylych (Роман Кирилич)

4 9

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-13-g1086950
by Dan McGee 23 Mar '08

23 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, maint has been updated via 1086950c82ab649ffc36a00cd8d343da376252fe (commit) via 7995a25d0ed75968df72fcf65d231508417ec060 (commit) from 7d451b6e6bc3926589a77e6a2d191e4f158d3980 (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 ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: lib/libalpm/add.c | 1 + lib/libalpm/backup.c | 3 +++ src/pacman/util.c | 2 +- 3 files changed, 5 insertions(+), 1 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-95-g5f1ccdb
by Dan McGee 23 Mar '08

23 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 5f1ccdbc27e3b4b92f9b65379db17a4d6523975d (commit) via d1ea16dfd0d497aff72d7a315890971e7f070786 (commit) via 6104f2e1fb872c32d3e6ed1823729592fc6245b9 (commit) via 1086950c82ab649ffc36a00cd8d343da376252fe (commit) via 7995a25d0ed75968df72fcf65d231508417ec060 (commit) via bf8670036907b3ede18d37b7a3f0f7e14542a5ac (commit) via 90a48c771d727e3bd231eeb1611dfcbecb88490c (commit) via f7f43dbb48add85c3c3e42696c4d3bae4591a7d6 (commit) via 3d10d460dff4c1321b40fa509c4ff9be93db0ca3 (commit) via 5af076f09f67bb3abd80a28fa3f33437f08b18bc (commit) from 2f8fb80ee631ef866c3bd8cb5fab09a7360ca8d2 (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 5f1ccdbc27e3b4b92f9b65379db17a4d6523975d Merge: d1ea16dfd0d497aff72d7a315890971e7f070786 1086950c82ab649ffc36a00cd8d343da376252fe Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 16:58:53 2008 -0500 Merge branch 'maint' commit d1ea16dfd0d497aff72d7a315890971e7f070786 Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Tue Mar 11 16:40:27 2008 +0100 Avoid duplicated target names. This patch should avoid duplicated target names in the backend. 1. sync_loadtarget will return with PM_ERR_TRANS_DUP_TARGET when trying to add a duplicated target 2. sysupgrade never pulls duplicated targets 3. resolvedeps won't pull duplicated targets anymore A pulled list was introduced in sync_prepare to improve the pmsyncpkg_t<->pmpkg_t list conversion by making it more direct. Also replace sync1005 and sync1006 by the sync1008 pactest, which is similar but more interesting (the provisions are dependencies instead of explicit targets). sync1005 didn't work as expected anyway. It was expecting that pacman failed, and pacman indeed failed, but not for the good reason. It didn't fail during the preparation step because of conflicting targets, but during the commit step, because of a md5 error... And sync1006 didn't pass and was not really worth fixing. We have already enough failing pactests more important than these two. sync1008 pass with this patch. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 6104f2e1fb872c32d3e6ed1823729592fc6245b9 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 15:35:22 2008 -0500 memleak fix: ensure we free result of get_destfile() In the file:// download case, we didn't free the return from get_destfile() after we were done with it. Fix it. (Found with xfercommand001.py) Signed-off-by: Dan McGee <dan(a)archlinux.org> commit bf8670036907b3ede18d37b7a3f0f7e14542a5ac Author: Dan McGee <dan(a)archlinux.org> Date: Sat Jan 12 01:13:52 2008 -0600 Switch pmgrp_t to dynamic allocation, general group cleanup Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 90a48c771d727e3bd231eeb1611dfcbecb88490c Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 14:25:38 2008 -0500 Add -q (quiet) option to valgrind call in pactest This gets rid of a lot of the unnecessary verbosity in the --valgrind output when running all the tests. It should also make diff-ing output between test runs a lot easier. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f7f43dbb48add85c3c3e42696c4d3bae4591a7d6 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 14:08:31 2008 -0500 Update database mtime after it has been extracted This will reduce the need for running an -Syy if the DB was only half-extracted, as the mtime won't get updated until the new database is completely in place. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 3d10d460dff4c1321b40fa509c4ff9be93db0ca3 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sat Feb 16 16:01:13 2008 +0100 Add new CleanMethod option. As it was already mentioned several times, the new -Sc behavior in 3.1 is great, but only when the package cache is not shared. This option has two possible values : KeepInstalled and KeepCurrent With KeepCurrent, -Sc will clean packages that are no longer available in any sync db, rather than packages that are no longer in the local db. The resulting behavior should be better for shared cache. Ref : http://www.archlinux.org/pipermail/pacman-dev/2008-February/011140.html Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 5af076f09f67bb3abd80a28fa3f33437f08b18bc Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sat Mar 15 21:10:54 2008 +0100 Kill the dependsonly option. From the man page : "This is pretty useless and we're not sure why it even exists." Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> ----------------------------------------------------------------------- Summary of changes: contrib/bash_completion | 1 - contrib/zsh_completion | 1 - doc/pacman.8.txt | 7 +- doc/pacman.conf.5.txt | 9 +++ lib/libalpm/add.c | 1 + lib/libalpm/alpm.h | 4 +- lib/libalpm/backup.c | 3 + lib/libalpm/cache.c | 50 ++++++-------- lib/libalpm/db.c | 20 +++-- lib/libalpm/deps.c | 6 +- lib/libalpm/dload.c | 11 ++-- lib/libalpm/group.c | 9 ++- lib/libalpm/group.h | 11 ++-- lib/libalpm/sync.c | 57 +++++++-------- pactest/pmtest.py | 2 +- pactest/tests/sync1001.py | 18 ----- pactest/tests/sync1002.py | 19 ----- pactest/tests/sync1006.py | 14 ---- pactest/tests/{sync1005.py => sync1008.py} | 11 ++- src/pacman/conf.h | 14 +++- src/pacman/pacman.c | 13 +++- src/pacman/query.c | 28 ++++---- src/pacman/sync.c | 106 ++++++++++++++++++++------- src/pacman/util.c | 2 +- 24 files changed, 221 insertions(+), 196 deletions(-) delete mode 100644 pactest/tests/sync1001.py delete mode 100644 pactest/tests/sync1002.py delete mode 100644 pactest/tests/sync1006.py rename pactest/tests/{sync1005.py => sync1008.py} (54%) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-11-g7d451b6
by Dan McGee 22 Mar '08

22 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, maint has been updated via 7d451b6e6bc3926589a77e6a2d191e4f158d3980 (commit) via d07001f3ab3000ab4bd7277549b58641b0d02f0a (commit) via 1f30845e41b6e315e4553fade891be0b46ac2470 (commit) from 6e4b020654481c3b9050c5125a567b0b32cadbc6 (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 ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: contrib/PKGBUILD.vim | 4 +- etc/pacman.conf.in | 14 +++++++++ po/zh_CN.po | 80 +++++++++++++++++++++++++------------------------- 3 files changed, 56 insertions(+), 42 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-85-g2f8fb80
by Dan McGee 22 Mar '08

22 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 2f8fb80ee631ef866c3bd8cb5fab09a7360ca8d2 (commit) via 7d451b6e6bc3926589a77e6a2d191e4f158d3980 (commit) via d07001f3ab3000ab4bd7277549b58641b0d02f0a (commit) via e7a2232934e2658c3c7827d2ce706c1a8f5301b9 (commit) via 73ab153c44a1581b4bcf1e64eb6042b0631c2e66 (commit) via b3e6cf652c9e989badaf5499abb1d64c1a110927 (commit) via dae3f9deefdb86f726a68dc89a7391e9df7517df (commit) via 1f30845e41b6e315e4553fade891be0b46ac2470 (commit) via 6e4b020654481c3b9050c5125a567b0b32cadbc6 (commit) via 6820be9ba1e760e66df1d4cc1a73c04b55bdb00a (commit) via 804ab37ea62602b04ae7b65c3e7fddda12bbae5d (commit) from 35135c0a0cbac592e72296c0ca64e9def0308942 (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 2f8fb80ee631ef866c3bd8cb5fab09a7360ca8d2 Merge: e7a2232934e2658c3c7827d2ce706c1a8f5301b9 7d451b6e6bc3926589a77e6a2d191e4f158d3980 Author: Dan McGee <dan(a)archlinux.org> Date: Sat Mar 22 11:11:22 2008 -0500 Merge branch 'maint' commit e7a2232934e2658c3c7827d2ce706c1a8f5301b9 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Mar 16 22:36:31 2008 +0100 Kill PM_TRANS_TYPE_ADD. This was totally useless. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 73ab153c44a1581b4bcf1e64eb6042b0631c2e66 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Mar 16 22:23:47 2008 +0100 Kill some obsolete references to -A option. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit b3e6cf652c9e989badaf5499abb1d64c1a110927 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Thu Mar 13 16:36:44 2008 +0100 Drop case insensitive comparisons in the config parsing. These case insensitive comparisons didn't work in some locales, like tr_TR where upper(i) != I. So a second case sensitive comparison had to be made for each directive. Only keeping case sensitive comparisons make the code cleaner and treat all locales equally. Ref: http://www.archlinux.org/pipermail/pacman-dev/2008-March/011445.html Also fix pactests to use the correct case. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit dae3f9deefdb86f726a68dc89a7391e9df7517df Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Thu Mar 13 00:25:38 2008 +0100 Add zipman makepkg option. All other steps in tidy_install function were already controlled by an option in makepkg.conf, so this patch adds an option for the man page compression step too. This will allow to keep man pages uncompressed, which is required for some special meta man page, like the zshall one (see FS#4580). Ref: http://www.archlinux.org/pipermail/pacman-dev/2008-March/011472.html Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> ----------------------------------------------------------------------- Summary of changes: contrib/PKGBUILD.vim | 12 ++-- contrib/bash_completion | 8 +- contrib/zsh_completion | 11 +--- doc/PKGBUILD.5.txt | 3 + doc/makepkg.conf.5.txt | 7 +- doc/pacman.conf.5.txt | 9 ++- etc/makepkg.conf.in | 5 +- etc/pacman.conf.in | 14 +++ lib/libalpm/add.c | 14 +--- lib/libalpm/alpm.h | 4 +- lib/libalpm/deps.c | 13 ++-- lib/libalpm/deps.h | 2 +- lib/libalpm/error.c | 2 - lib/libalpm/remove.c | 2 +- lib/libalpm/sync.c | 2 +- lib/libalpm/trans.c | 3 - pactest/tests/remove030.py | 2 +- pactest/tests/sync021.py | 2 +- pactest/tests/sync120.py | 2 +- pactest/tests/sync133.py | 2 +- pactest/tests/sync138.py | 2 +- pactest/tests/upgrade010.py | 2 +- pactest/tests/upgrade070.py | 2 +- pactest/tests/xfercommand001.py | 2 +- pactest/util.py | 2 +- po/zh_CN.po | 172 ++++++++++++++++++++------------------- scripts/makepkg.sh.in | 64 ++++++++------- src/pacman/pacman.c | 52 +++++------- 28 files changed, 206 insertions(+), 211 deletions(-) hooks/post-receive -- The official pacman repository

1 0