- Pacman-dev - lists.archlinux.org

[pacman-dev] Hooks for pacman
by Allan McRae 23 Jan '09

23 Jan '09

Hi all, A new feature I am ever so slightly obsessed about at the moment is the possibility of having hooks in pacman for doing common tasks in install files. e.g. adding info pages to directory, updating font/icon/.desktop cache, gconf stuff... So, how would this be implemented? Here is my outline: Two types of hooks would be needed for both install and remove. One type that is run for every matching file (e.g. info install) and one type that is run once per transaction (e.g. font cache update). These could be stored in /etc/pacman.d/hooks/ with an index of hooks in /etc/pacman.d/hooks.conf. The .conf file could look something like: [add] PerFile = infopage /usr/share/info/ PerTrans = fontcache /usr/share/fonts/ [remove] ... That needs improvement, but that covers the information that needs presented - whether the hook is run per file or per transaction, the name of the hook and the directory whose files set off this hook. Maybe the conditions that set the hook off should be in the actual hook file. I guess the actual hook would look look just like: hook() { do stuff here... } I figure we must already generate a list of all the files being added/removed during conflict checks, so we would "just" need to scan that list for what hooks need to be run and actually run them. Anyway, I thought I would post this idea here so I could get more feedback on the implementation and maybe convince someone to code it... Allan

4 7

[pacman-dev] patches needed for splitpkg work
by Allan McRae 21 Jan '09

21 Jan '09

Hi all, I am a bit busy with $DAYJOB at the moment so I thought I would post some of the things that need tidied up in makepkg (mainly for the splitpkg implementation) so others might fix them. These are all fairly trivial and probably just need a loop over ${pkgname[*]}: - check all packages in "exists" checks (package and source package) - fix cleanup of log files (note change in file name in build() & package() function) - fix delta creation - fix install packages This is a bit more in depth... (probably requires backup and restore) - value of "$pkgname" in build() & package() functions These require discussion on how best to fix. I thought of adding a grpname entry in the PKGBUILD for this and defaulting to $pkgname[0] if not present. Opinions? - pkgname used for source package (??? what to use...) - how to deal with $pkgname in messages - "is not available for the ? architecture" - "Making package" - "Finished making" Cheers, Allan

1 0

[pacman-dev] My patches (again)
by Bryan Ischo 21 Jan '09

21 Jan '09

Hi all. I've noticed that other commits have gone into the pacman master repository (what is the exact git terminology for the master repository?) but that the patches that I sent to the list have not. Are mine going in? Or is the team waiting on something from me? Or have my patches been rejected? My most recent emails should have patches which easily and cleanly apply to the tree. Thanks, Bryan

3 3

Re: [pacman-dev] icadyptes makepkg changes
by Teran McKinney 20 Jan '09

20 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I was subscribed to the pacman-dev list on my old email account, but just moved it over. I noticed the thread about Icadyptes' makepkg changes and got Allan's message. I would be happy to see some of Icadyptes' makepkg changes make it into the mainline makepkg, but I doubt all of them will (on top of that, some of my code is quite hackish). Some features are implemented nicely, though others are definitely a work in progress. Most changes were applied to the 3.2.1 makepkg, and I have not updated it for split package support and some of the other changes. I will list the changes I can remember by order of how useful I think they would be to the mainline makepkg. Most useful: runtimedeps=(): I added a runtimedeps=() option for dependencies that are needed at runtime and not for building. This would be useful for scripts that only need a `make install DESTDIR="$pkgdir"` on the building side. I've used it a few times already, but it is not the most common case. Not setting arch=() implies arch=('any'): After a couple months of development, some benchmarks, and finding that AMD K6-2s lack the CMOV instruction, I moved Icadyptes to i486/generic. It is frustrating (though scriptable) to change all buildscripts from arch=('i686' 'x86_64) to arch=('i486' 'x86_64), but I did not care for the setup from the begining. Rarely is a source tarball only buildable on one x86 subset, and I don't like having to write arch=('any') in each buildscript, so I made arch=('any') the default if no arch line was set. I think that this could be expanded a bit with negation flags for archs, ie arch=('!i486' 'i686'). Or perhaps arch=('i586+'), but that is getting a little complex and overdone in my opinion. Potentially useful: Replacing checksums inside the PKGBUILD with SHA256SUMs in a CHECKSUMS file: Originally, I kept the {md5,sha1}sums=() lines in buildscripts, but couldn't be bothered to update them if the source files were updated. This needs a lot of work, but I simplified the code gutting the PKGBUILD-internal checksums and replaced it with a seperate CHECKSUMS file containing SHA256SUMs of $source=() and $install. One can simply run `makepkg -g` to regenerate the checksums now, which is quite nice. Other scripts would have to be updated to copy CHECKSUMS over, but I have had no issues with it after some minor tweaking here. $SRCDEST using SHA256SUMs as the filenames: This needs work too, but if you are using a shared source directory makepkg will download the source files, verify them against CHECKSUMS, and move them to $SRCDEST. Using $SRCDEST with the normal filenames is problematic due to filename collision with other packages, so this is an (IMO) elegant and safe solution. I used SHA256 because MD5 is very insecure, SHA1 is potentially vulnerable, and it isn't as overkill (though some would say SHA256 is excessive) as SHA512. While an attacker could do a number of attacks to give the user faulty build scripts, at least this part of the system is secure. Of course, any checksum algorithim can be used. Doubt you would want these: Removal of OS X hacks: I can mostly understand using alternative utilities so that *BSDs can use makepkg, but I have no idea of why you care about Mac OS X enough to implement slower and more bloated workarounds to things like getopt. In my opinion, you have to draw the line somewhere. I personally think that makepkg and Pacman should be solely for Arch, but that is just my two cents. Removal of OpenSSL dependencies: I don't care for OpenSSL and try to replace it with GnuTLS where I can, so I reverted back to using the *sum utilities. GnuTLS is lighter, easier to build, and doesn't have the advertising license clause that OpenSSL does. Of course, the *sum utilities are from GNU coreutils, not GnuTLS. Moving to GNU tar from bsdtar so that libarchive can eventually be removed entirely as a package. Although libarchive looks fairly nice, so I should do some more research on this. Pacman changes: Pacman is currently pretty vanilla in Icadyptes, but I apply the reverted patch for internal file:// handling, statically link it against libarchive, use curl (you may want to look at my {pacman,makepkg}.conf as they pass a couple more flags), and generally have fairly light configure options (disabling NLS, etc.). I also use .ipkg for the package extension, but I don't think any of this is very usable by the mainstream Pacman :-). Thanks for the interest in my makepkg modifications. Let me know if you have any comments, ideas, or suggestions. Cheers, Teran (sega01) On Tue, 20 Jan 2009 14:58:50 +0000 "Teran McKinney" <sega01(a)gmail.com> wrote: > Forwarded conversation > Subject: [pacman-dev] icadyptes makepkg changes > ------------------------ > > From: Allan McRae <allan(a)archlinux.org> > Date: Tue, Jan 20, 2009 at 12:20 > To: Discussion list for pacman development <pacman-dev(a)archlinux.org> > > > Hi, > > This is a reminder for myself and a FYI for anyone else that is > interested. There is a new Arch fork called Icadyptes > (http://icadyptes.org/) which does some changes to makepkg and to a > lesser extend pacman (see http://icadyptes.org/index.php?q=node/2) > Their git repo is here: > http://gitweb.icadyptes.org/?p=icadyptes-core/.git;a=tree;f=base/pacman;hb=… > > Maybe there is something useful there that would worth merging. > Adding something like "runtimedeps" has been previously suggested but > from memory the patch never got updated for inclusion. Other makepkg > changes listed will probably never make it here... > Anyway, I will give the Icadyptes dev a ping to suggest that any > changes could/should be CCed here so we can decide whether to include > them. > > Allan > > > _______________________________________________ > pacman-dev mailing list > pacman-dev(a)archlinux.org > http://www.archlinux.org/mailman/listinfo/pacman-dev > > ---------- > From: Dan McGee <dpmcgee(a)gmail.com> > Date: Tue, Jan 20, 2009 at 13:48 > To: Discussion list for pacman development <pacman-dev(a)archlinux.org> > > > Their changes do sound interesting. Please do send them an email. > > -Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iF4EAREIAAYFAkl2HbQACgkQPsLC06eiyfF1CwD/dl9UgD7VK+5NDnNzSJhFL+kZ u50RnWVRx1ZxikzBVXsBAK6vh2PpdWva05+0cZL563DtWP/q+SXMLiECQCl0WsnM =4/Q8 -----END PGP SIGNATURE-----

1 0

[pacman-dev] [PATCH 1/3] alpm_unpack : change prefix handling to workaround FS#12148.
by Xavier Chantry 20 Jan '09

20 Jan '09

Instead of appending the prefix to each entry name, we can chdir to the prefix before extracting, and restoring when it is done. This seems to work better with the strange and special case of FS#12148 where an archive contained the "./" entry. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> --- lib/libalpm/util.c | 31 +++++++++++++++++++++++-------- 1 files changed, 23 insertions(+), 8 deletions(-) diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c index 1bec634..2af2f1f 100644 --- a/lib/libalpm/util.c +++ b/lib/libalpm/util.c @@ -291,16 +291,17 @@ int _alpm_lckrm() */ int _alpm_unpack(const char *archive, const char *prefix, const char *fn) { - int ret = 1; + int ret = 0; mode_t oldmask; struct archive *_archive; struct archive_entry *entry; - char expath[PATH_MAX]; + char cwd[PATH_MAX]; + int restore_cwd = 0; ALPM_LOG_FUNC; if((_archive = archive_read_new()) == NULL) - RET_ERR(PM_ERR_LIBARCHIVE, -1); + RET_ERR(PM_ERR_LIBARCHIVE, 1); archive_read_support_compression_all(_archive); archive_read_support_format_all(_archive); @@ -309,10 +310,25 @@ int _alpm_unpack(const char *archive, const char *prefix, const char *fn) ARCHIVE_DEFAULT_BYTES_PER_BLOCK) != ARCHIVE_OK) { _alpm_log(PM_LOG_ERROR, _("could not open %s: %s\n"), archive, archive_error_string(_archive)); - RET_ERR(PM_ERR_PKG_OPEN, -1); + RET_ERR(PM_ERR_PKG_OPEN, 1); } oldmask = umask(0022); + + /* save the cwd so we can restore it later */ + if(getcwd(cwd, PATH_MAX) == NULL) { + _alpm_log(PM_LOG_ERROR, _("could not get current working directory\n")); + } else { + restore_cwd = 1; + } + + /* just in case our cwd was removed in the upgrade operation */ + if(chdir(prefix) != 0) { + _alpm_log(PM_LOG_ERROR, _("could not change directory to %s (%s)\n"), prefix, strerror(errno)); + ret = 1; + goto cleanup; + } + while(archive_read_next_header(_archive, &entry) == ARCHIVE_OK) { const struct stat *st; const char *entryname; /* the name of the file in the archive */ @@ -337,10 +353,6 @@ int _alpm_unpack(const char *archive, const char *prefix, const char *fn) } /* Extract the archive entry. */ - ret = 0; - snprintf(expath, PATH_MAX, "%s/%s", prefix, entryname); - archive_entry_set_pathname(entry, expath); - int readret = archive_read_extract(_archive, entry, 0); if(readret == ARCHIVE_WARN) { /* operation succeeded but a non-critical error was encountered */ @@ -361,6 +373,9 @@ int _alpm_unpack(const char *archive, const char *prefix, const char *fn) cleanup: umask(oldmask); archive_read_finish(_archive); + if(restore_cwd) { + chdir(cwd); + } return(ret); } -- 1.6.1

3 4

[pacman-dev] icadyptes makepkg changes
by Allan McRae 20 Jan '09

20 Jan '09

Hi, This is a reminder for myself and a FYI for anyone else that is interested. There is a new Arch fork called Icadyptes (http://icadyptes.org/) which does some changes to makepkg and to a lesser extend pacman (see http://icadyptes.org/index.php?q=node/2) Their git repo is here: http://gitweb.icadyptes.org/?p=icadyptes-core/.git;a=tree;f=base/pacman;hb=… Maybe there is something useful there that would worth merging. Adding something like "runtimedeps" has been previously suggested but from memory the patch never got updated for inclusion. Other makepkg changes listed will probably never make it here... Anyway, I will give the Icadyptes dev a ping to suggest that any changes could/should be CCed here so we can decide whether to include them. Allan

2 1

[pacman-dev] [PATCH] db_register: Unlink DbPath/database, if it is not a directory
by Nagy Gabor 19 Jan '09

19 Jan '09

From 884155e03bf20f1cca880f39848423091729f6cd Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Mon, 19 Jan 2009 00:35:45 +0100 Subject: [PATCH] db_register: Unlink DbPath/database, if it is not a directory We had a check for this case, but we didn't handle it at all (neither error, nor fix), we also had a TODO in the code. For example, if user has an "unstable" regular file instead of "unstable" directory (FS#12148), from now on pacman will remove that file (and print a warning message). Before this patch pacman just stopped with "could not register database" error. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/db.c | 18 ++++++++++++++---- 1 files changed, 14 insertions(+), 4 deletions(-) diff --git a/lib/libalpm/db.c b/lib/libalpm/db.c index 9b91ce4..fe886ae 100644 --- a/lib/libalpm/db.c +++ b/lib/libalpm/db.c @@ -452,13 +452,18 @@ pmdb_t *_alpm_db_register_local(void) RET_ERR(PM_ERR_DB_OPEN, NULL); } snprintf(path, PATH_MAX, "%slocal", dbpath); - /* TODO this is rediculous, we try to do this even if we can't */ - if(stat(path, &buf) != 0 || !S_ISDIR(buf.st_mode)) { + + if(stat(path, &buf) != 0) { _alpm_log(PM_LOG_DEBUG, "database dir '%s' does not exist, creating it\n", path); if(_alpm_makepath(path) != 0) { RET_ERR(PM_ERR_SYSTEM, NULL); } + } else if(!S_ISDIR(buf.st_mode)) { + _alpm_log(PM_LOG_WARNING, "removing bogus database: %s\n", path); + if(unlink(path) != 0 || _alpm_makepath(path) != 0) { + RET_ERR(PM_ERR_SYSTEM, NULL); + } } db = _alpm_db_new(dbpath, "local"); @@ -504,13 +509,18 @@ pmdb_t *_alpm_db_register_sync(const char *treename) } /* all sync DBs now reside in the sync/ subdir of the dbpath */ snprintf(path, PATH_MAX, "%ssync/%s", dbpath, treename); - /* TODO this is rediculous, we try to do this even if we can't */ - if(stat(path, &buf) != 0 || !S_ISDIR(buf.st_mode)) { + + if(stat(path, &buf) != 0) { _alpm_log(PM_LOG_DEBUG, "database dir '%s' does not exist, creating it\n", path); if(_alpm_makepath(path) != 0) { RET_ERR(PM_ERR_SYSTEM, NULL); } + } else if(!S_ISDIR(buf.st_mode)) { + _alpm_log(PM_LOG_WARNING, "removing bogus database: %s\n", path); + if(unlink(path) != 0 || _alpm_makepath(path) != 0) { + RET_ERR(PM_ERR_SYSTEM, NULL); + } } /* Ensure the db gets the real path. */ -- 1.6.1

2 2

[pacman-dev] pacman mirrors
by Amanai 19 Jan '09

19 Jan '09

I don't know what to do, but I know with the last pacman update with a seperated mirror list, my download speed went down to 40-80 k/sec. Before it was around 1700-2000 k/sec, using cable with 30 Mbits. I try to find the fastest server, but can't. Is it possible that pacman can use "geo_ip", that automatically find the nearest and fastest server. This works perfect with my openSUSE box. Now it looks like, after running pacman -Syu I spend a day to get all updates. I was set up mirror after mirror from this list http://users.archlinux.de/~gerbra/mirrorcheck.html the fastest I get now are 200 k/sec. with a Server out of date. ~ 10 hours out of date. Where is the fast california server gone?

2 1

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.2.2-4-g472e51b
by dan＠archlinux.org 18 Jan '09

18 Jan '09

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 472e51b975b9cb8fe1f67c03ff72bbc067fa7f01 (commit) from 1191303f8b9edc01ff969e2433f5c40c9a95474a (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 | 4 ++-- lib/libalpm/util.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.2.2-73-gc794661
by dan＠archlinux.org 18 Jan '09

18 Jan '09

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 c794661f1ea8c819d479948e92e5648de62787c5 (commit) via 8929769902597f109fc6b49609fb64121becb197 (commit) via 350c3eb6ec25b91b0402fa86422a7312ba7330d6 (commit) via 472e51b975b9cb8fe1f67c03ff72bbc067fa7f01 (commit) from fba5771fa4c774457531a4bbbcd66340c7c3fb6a (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 c794661f1ea8c819d479948e92e5648de62787c5 Merge: 8929769902597f109fc6b49609fb64121becb197 472e51b975b9cb8fe1f67c03ff72bbc067fa7f01 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jan 18 13:48:48 2009 -0600 Merge branch 'maint' commit 8929769902597f109fc6b49609fb64121becb197 Author: Dan McGee <dan(a)archlinux.org> Date: Sat Jan 17 09:51:48 2009 -0600 makepkg: test fixes, part 2 The goal of this fix was empty string comparisons: - if [ "$pkgname" != "" ]; then + if [ -n "$pkgname" ]; then Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 350c3eb6ec25b91b0402fa86422a7312ba7330d6 Author: Dan McGee <dan(a)archlinux.org> Date: Sat Jan 17 09:42:23 2009 -0600 makepkg: clean up test usage In a lot of places, we had the following construct: [ "$foobar" = "0" ] which is better represented by using the integer tests: [ $foobar -eq 0 ] Attempt to unify makepkg to use the latter rather than the former in all places. From here on out we should ensure anything that is set to 0, 1, etc. uses the -eq format rather than =. In addition, fix a few other test anomalies including usage of double equals. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/add.c | 4 +- lib/libalpm/util.c | 4 +- scripts/makepkg.sh.in | 135 +++++++++++++++++++++++++------------------------ 3 files changed, 72 insertions(+), 71 deletions(-) hooks/post-receive -- The official pacman repository

1 0