Re: [pacman-dev] little translation error
2012/2/26 solsTiCe d'Hiver solstice.dhi...@gmail.com: hi. I have sent a message about that to shining on transifex, but it seems to go unnoticed so I am reposting it here Sorry, I did not realize it was a private message. The advantage of transifex is that everyone can contribute directly to the translation, I can add you to the team, even if it's only for one little fix like that once per year :)
Re: [pacman-dev] [PATCH] Handle removal of empty directories properly
On Sat, Jul 16, 2011 at 5:11 PM, Dan McGee d...@archlinux.org wrote: This addresses FS#25141. We shouldn't remove every empty directory we come across during the removal process unless it is truly not known to any other package. This will prevent removal of essential directories such as '/var/lock/'. This is accomplished by first checking the empty/non-empty status of a directory, which was previously done implicitly by calling rmdir() and ignoring errors. We do this to avoid the next (new) check in most cases, which is to look at all local packages to see if the to-be-removed directory is present in another packages' filelist. If we do not find it anywhere, then we remove it, else we keep the file around. I always thought pacman should do that, but Nagy concerns were obviously right, loading /var/lib/pacman/local/*/files takes time. This just highlights once more the poor design of the local db. pacman -R teeworlds goes from 2sec to 12sec here (after dropping caches) ... and from 0.4sec to 0.7sec when everything is cached. But only a pacman -Qo 'orphaned_file' or a previous -R operation would load all /var/lib/pacman/local/*/files Just to make myself clear, I think this patch should go in, and the local db out :) In the meantime, we have filesystem loops fortunately.
Re: [pacman-dev] [PATCH] Simplify alpm_list_previous
On Mon, Jul 4, 2011 at 4:16 AM, Allan McRae al...@archlinux.org wrote: We can readily detect the first node in a list by checking if node-prev-next is NULL. So there is no need to pass the head of the list to this function and its prototype now looks like all the other item accessors. This works even for single item list where the first item is the last, so node-prev == node. ACK
Re: [pacman-dev] [PATCH v2] makepkg: Add support for verifying pgp signatures
On Mon, Jul 4, 2011 at 4:36 PM, Allan McRae al...@archlinux.org wrote: I still wonder if --skippgpcheck is too long, but I can not think of a better name. Suggestions from anyone? --skipinteg / --skipsig or --skippgp ? +*\--skippgpcheck*:: + Verify PGP signatures of the source files if provided in the build script. + Skip verification of PGP signatures ?
Re: [pacman-dev] [PATCH] Remove old TODO lists
On Wed, Jun 22, 2011 at 10:54 AM, Allan McRae al...@archlinux.org wrote: These had not been touched since 2007 and had lost most of their relevance. The bug tracker is a better place for the filing of ideas. Agreed, but if some items are not completely obsolete and don't appear anywhere in the bug tracker, they should probably be added then.
Re: [pacman-dev] Thoughts on database initialization and loading process
On Sun, Apr 17, 2011 at 9:32 AM, Rémy Oudompheng remyoudomph...@gmail.com wrote: We are looking at a broader problem: it is actually impossible to do any sane return value checking for all functions returning an alpm_list_t* since NULL is used both as the error value and as the empty list. [adding to this the fact that I am really not a fan of linked lists especially when there doesn't seem to be any reason to use them. NULL-terminated arrays of pointers work in almost all cases] I suggest adding a special value to return when an error occurs. Something like this: callers would check the value of pm_errno whenever return value == pm_listerror. IMO it looks better to return an int and give an alpm_list ** as argument.
Re: [pacman-dev] [PATCH] Remove dead stores reported by clang-analyzer
On Sun, Apr 3, 2011 at 8:14 AM, Sebastian Nowicki seb...@gmail.com wrote: Signed-off-by: Sebastian Nowicki seb...@gmail.com --- lib/libalpm/be_local.c | 2 +- lib/libalpm/pkghash.c | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) I didn't send these yesterday to the ML as they looked trivial enough, but maybe I should have. http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working
Re: [pacman-dev] gnu89-inline
On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki seb...@gmail.com wrote: Looks like there are more warnings when using gnu89: $ make 21 | grep 'warning:' | cut -d' ' -f3- | sort | uniq -c 74 comma at end of enumerator list 1 initializer element is not computable at load time 7 ISO C90 does not support the 'j' gnu_printf length modifier 106 ISO C90 does not support the 'z' gnu_printf length modifier 41 ISO C90 forbids mixed declarations and code 57 ISO C90 forbids specifying subobject to initialize There are lots of duplicates (173 - 58 warnings after removing them). 4 commas at the end of enumerator lists are a C99-specific feature [-pedantic] 2 extension used [-pedantic] 50 ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement] 2 variable declaration in for loop is a C99-specific feature [-pedantic] Seems like I was also confused by the high number of repetition of the first warning in my previous post. My opinion is still the same though : - commas the end of enum lists : much nicer for adding new items at the end - variable declaration in for loop : further reducing of variable scope. its silly to always need to put the i in the outer block.
Re: [pacman-dev] gnu89-inline
On Sun, Apr 3, 2011 at 10:04 AM, Xavier Chantry chantry.xav...@gmail.com wrote: On Sun, Apr 3, 2011 at 6:55 AM, Sebastian Nowicki seb...@gmail.com wrote: Looks like there are more warnings when using gnu89: $ make 21 | grep 'warning:' | cut -d' ' -f3- | sort | uniq -c 74 comma at end of enumerator list 1 initializer element is not computable at load time 7 ISO C90 does not support the 'j' gnu_printf length modifier 106 ISO C90 does not support the 'z' gnu_printf length modifier 41 ISO C90 forbids mixed declarations and code 57 ISO C90 forbids specifying subobject to initialize There are lots of duplicates (173 - 58 warnings after removing them). 4 commas at the end of enumerator lists are a C99-specific feature [-pedantic] 2 extension used [-pedantic] 50 ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement] 2 variable declaration in for loop is a C99-specific feature [-pedantic] Actually that was the clang result while Seb posted results with gcc. In that case, removing duplicates goes from 286 to 214 (mostly comma at end of enumerator list from alpm.h) grep warning make-gcc.log | sort -u | cut -d' ' -f3- | sort | uniq -c 4 comma at end of enumerator list 1 initializer element is not computable at load time 6 ISO C90 does not support the 'j' gnu_printf length modifier 105 ISO C90 does not support the 'z' gnu_printf length modifier 41 ISO C90 forbids mixed declarations and code 57 ISO C90 forbids specifying subobject to initialize
[pacman-dev] [PATCH 1/2] configure.ac: we use fabs now so -lm is needed
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- configure.ac |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 3299302..9fb9cb0 100644 --- a/configure.ac +++ b/configure.ac @@ -131,6 +131,9 @@ AC_PATH_PROGS([BASH_SHELL], [bash bash4 bash3], [false]) AM_GNU_GETTEXT([external]) AM_GNU_GETTEXT_VERSION(0.13.1) +AC_CHECK_LIB([m], [fabs], , + AC_MSG_ERROR([libm is needed to compile pacman!])) + # Check for libarchive AC_CHECK_LIB([archive], [archive_read_data], , AC_MSG_ERROR([libarchive is needed to compile pacman!])) -- 1.7.4.2
[pacman-dev] [PATCH 2/2] dload: dont forget to initialize open_mode !
That's a funny one, building with optimization levels (with both gcc and
clang) caused open_mode to always be set to ab, which worked.
This was spotted both with clang-analyzer, and by Jakob who reported a
segfault as he was using an un-optimized build.
Maybe we should build with -O0 in debug mode.
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
lib/libalpm/dload.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
index d9e9488..4ebc868 100644
--- a/lib/libalpm/dload.c
+++ b/lib/libalpm/dload.c
@@ -159,7 +159,8 @@ static int curl_download_internal(const char *url, const
char *localpath,
{
int ret = -1;
FILE *localf = NULL;
- const char *open_mode, *useragent;
+ const char *useragent;
+ const char *open_mode = wb;
char *destfile, *tempfile;
char hostname[256]; /* RFC1123 states applications should support this
length */
struct stat st;
--
1.7.4.2
[pacman-dev] gnu89-inline
I am just curious, what do we need this flag for ? I only found this : http://gcc.gnu.org/onlinedocs/gcc/Inline.html GCC implements three different semantics of declaring a function inline. One is available with -std=gnu89 or -fgnu89-inline or when gnu_inline attribute is present on all inline declarations, another when -std=c99, -std=c1x, -std=gnu99 or -std=gnu1x (without -fgnu89-inline), and the third is used when compiling C++. There is a small annoyance with clang, the configure check believes fgnu89-inline is supported because clang only emits a warning when that flag is specified : checking for -fgnu89-inline... yes So every libalpm file triggers this warning when building : clang: warning: argument unused during compilation: '-fgnu89-inline' Anyway it looks like we could use -std=gnu89 alternatively ? ... which brings to another topic that was brought recently on the ML : I tried to build with that and got a lot of warnings :) ../../lib/libalpm/alpm.h:396:29: warning: commas at the end of enumerator lists are a C99-specific feature [-pedantic] pacman.c:1201:8: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement] util.c:797:8: warning: variable declaration in for loop is a C99-specific feature [-pedantic] ...
Re: [pacman-dev] gnu89-inline
On Sat, Apr 2, 2011 at 7:49 PM, Dan McGee dpmc...@gmail.com wrote: On Sat, Apr 2, 2011 at 12:17 PM, Xavier Chantry chantry.xav...@gmail.com wrote: I am just curious, what do we need this flag for ? Searching commits, it wasn't too hard to find this, although I don't know the full context or relevance. Not sure if it was just a GCC bug at the time? commit d8e88aa0175fd950d007578ea0690952f49247f1 Author: Dan McGee d...@archlinux.org Date: Tue Jun 5 17:32:09 2007 -0400 Fix compilation with GCC 4.2.0 'inline' keyword in C99 is not correctly recognized, so compilation fails on the warning it spits. This fixes this. Signed-off-by: Dan McGee d...@archlinux.org I also see this in the GCC 4.2.0 release notes, which is surely what I was referring to at the time: In the next release of GCC, 4.3, -std=c99 or -std=gnu99 will direct GCC to handle inline functions as specified in the C99 standard. In preparation for this, GCC 4.2 will warn about any use of non-static inline functions in gnu99 or c99 mode. This new warning may be disabled with the new gnu_inline function attribute or the new -fgnu89-inline command-line option. Also, GCC 4.2 and later will define one of the preprocessor macros __GNUC_GNU_INLINE__ or __GNUC_STDC_INLINE__ to indicate the semantics of inline functions in the current compilation. So now the question is whether you still want to support gcc 4.2 ? You are always much more conservative than I am :) Anyway it looks like we could use -std=gnu89 alternatively ? ... which brings to another topic that was brought recently on the ML : I tried to build with that and got a lot of warnings :) ../../lib/libalpm/alpm.h:396:29: warning: commas at the end of enumerator lists are a C99-specific feature [-pedantic] pacman.c:1201:8: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement] util.c:797:8: warning: variable declaration in for loop is a C99-specific feature [-pedantic] How many are there; did you just trim the list down? If it is easy to fix then we might think about doing so. Yes there were many in total, several of each. IMO warning 1 and 3 are must-have c99 features so I am for using these everywhere and certainly not for removing them :) I am fine with fixing declaration-after-statement, and IIRC there were just a few.
[pacman-dev] [PATCH 3/7] libalpm: switch default VerifySig to Optional
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
lib/libalpm/alpm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index b08191d..81877cc 100644
--- a/lib/libalpm/alpm.h
+++ b/lib/libalpm/alpm.h
@@ -254,8 +254,8 @@ int alpm_db_check_pgp_signature(pmdb_t *db);
/* GPG signature verification option */
typedef enum _pgp_verify_t {
- PM_PGP_VERIFY_ALWAYS,
PM_PGP_VERIFY_OPTIONAL,
+ PM_PGP_VERIFY_ALWAYS,
PM_PGP_VERIFY_NEVER
} pgp_verify_t;
--
1.7.4.2
[pacman-dev] [PATCH 7/7] pacman/query: correctly handle root files with -Qo
spotted by clang-analyzer (strcmp with NULL rpath is bad)
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/pacman/query.c | 50 +-
1 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/src/pacman/query.c b/src/pacman/query.c
index d2bfe69..d27044e 100644
--- a/src/pacman/query.c
+++ b/src/pacman/query.c
@@ -92,6 +92,16 @@ static int search_path(char **filename, struct stat *bufptr)
return -1;
}
+static void print_query_fileowner(const char *filename, pmpkg_t *info)
+{
+ if (!config-quiet) {
+ printf(_(%s is owned by %s %s\n), filename,
+ alpm_pkg_get_name(info),
alpm_pkg_get_version(info));
+ } else {
+ printf(%s\n, alpm_pkg_get_name(info));
+ }
+}
+
static int query_fileowner(alpm_list_t *targets)
{
int ret = 0;
@@ -156,17 +166,21 @@ static int query_fileowner(alpm_list_t *targets)
bname = mbasename(filename);
dname = mdirname(filename);
- rpath = resolve_path(dname);
+ /* for files in '/', there is no directory name to match */
+ if (strcmp(dname, ) == 0) {
+ rpath = NULL;
+ } else {
+ rpath = resolve_path(dname);
- /* this odd conditional is to ensure files in '/' can be
checked */
- if(!rpath strcmp(dname, ) != 0) {
- pm_fprintf(stderr, PM_LOG_ERROR, _(cannot determine
real path for '%s': %s\n),
- filename, strerror(errno));
- free(filename);
- free(dname);
- free(rpath);
- ret++;
- continue;
+ if(!rpath) {
+ pm_fprintf(stderr, PM_LOG_ERROR, _(cannot
determine real path for '%s': %s\n),
+ filename, strerror(errno));
+ free(filename);
+ free(dname);
+ free(rpath);
+ ret++;
+ continue;
+ }
}
free(dname);
@@ -183,6 +197,13 @@ static int query_fileowner(alpm_list_t *targets)
continue;
}
+ /* for files in '/', there is no directory name
to match */
+ if(!rpath) {
+ print_query_fileowner(filename, info);
+ found = 1;
+ continue;
+ }
+
if(strlen(pkgfile) max_length) {
pm_fprintf(stderr, PM_LOG_ERROR,
_(path too long: %s%s\n), root, pkgfile);
}
@@ -194,12 +215,7 @@ static int query_fileowner(alpm_list_t *targets)
free(pdname);
if(ppath strcmp(ppath, rpath) == 0) {
- if (!config-quiet) {
- printf(_(%s is owned by %s
%s\n), filename,
-
alpm_pkg_get_name(info), alpm_pkg_get_version(info));
- } else {
- printf(%s\n,
alpm_pkg_get_name(info));
- }
+ print_query_fileowner(filename, info);
found = 1;
}
free(ppath);
--
1.7.4.2
Re: [pacman-dev] libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)
On Sat, Mar 19, 2011 at 9:27 PM, Lukas Fleischer archli...@cryptocrack.de wrote: Yes, this definitely is a libtool issue. It just seems to link all indirect library dependencies. We can circumvent this by linking with -Wl,--as-needed but I'm not sure whether this is a valid workaround (especially since I'm not sure how this will affect other platforms). I will submit that patch for further testing tho. Just to clarify with what was said in the other thread : arch uses -Wl,--as-needed by default (makepkg.conf LDFLAGS) and this flag can be seen in my two outputs above. But not in the right place, and that's what the debian patch fixes. And there was definitely a behavior change with that pacman libtool upgrade in the usage of dependency_libs from .la files, but I cannot tell whether it's a feature or a bug :)
Re: [pacman-dev] [PATCH] Fix handling of ignored packages
On Sat, Mar 19, 2011 at 9:09 AM, Pang Yan Han pangyan...@gmail.com wrote: Noted in FS#23342. When the user attempts to install an ignored package and answers no when asked whether to install it, pacman bails out with: error: target not found: packagename This is because satisfiers are not found for the package and execution continues to process_group(), where the package is treated as a group (which does not exist). In addition, test ignore006.py is updated with PACMAN_RETCODE=0 since saying no to installing an ignored package should not be considered an error. Signed-off-by: Pang Yan Han pangyan...@gmail.com --- Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
Re: [pacman-dev] libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)
On Fri, Mar 18, 2011 at 3:18 PM, Lukas Fleischer archli...@cryptocrack.de wrote: Well, it actually is a bit more than just a wrong dependency. ioni and me figured that libalpm 6.0.0 is linked against all libfetch and libarchive dependencies as well whereas 5.0.3 isn't, so there must have been some changes in the build system causing these trouble. I `git bisect`'ed the commit that introduced this regression. f489e969 [1] includes autotools upgrades and probably some more changes which seem to trigger this. Maybe someone else can have a closer look (I unfortunately don't have any more time and this is a rather large commit). I added these information to the related ticket [2] as well. [1] http://projects.archlinux.org/pacman.git/commit/?id=f489e969 [2] https://bugs.archlinux.org/task/23325 This commit definitely changes the command line. All deps coming from $(pkg-config --libs --static libarchive) appear after /usr/lib/libarchive.so After : make.log:libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto -O2 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1 Before : make-good.log:gcc -std=gnu99 -shared .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1
Re: [pacman-dev] libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)
On Sat, Mar 19, 2011 at 10:36 AM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Mar 18, 2011 at 3:18 PM, Lukas Fleischer archli...@cryptocrack.de wrote: Well, it actually is a bit more than just a wrong dependency. ioni and me figured that libalpm 6.0.0 is linked against all libfetch and libarchive dependencies as well whereas 5.0.3 isn't, so there must have been some changes in the build system causing these trouble. I `git bisect`'ed the commit that introduced this regression. f489e969 [1] includes autotools upgrades and probably some more changes which seem to trigger this. Maybe someone else can have a closer look (I unfortunately don't have any more time and this is a rather large commit). I added these information to the related ticket [2] as well. [1] http://projects.archlinux.org/pacman.git/commit/?id=f489e969 [2] https://bugs.archlinux.org/task/23325 This commit definitely changes the command line. All deps coming from $(pkg-config --libs --static libarchive) appear after /usr/lib/libarchive.so After : make.log:libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto -O2 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1 Before : make-good.log:gcc -std=gnu99 -shared .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1 still did not get to the bottom of this, but all these libarchive deps comes from libarchive.la : # Libraries that this one depends upon. dependency_libs=' -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto' This is needed for a static build of pacman, but an alternative is to use pkg-config --static --libs libarchive somewhere in the Makefile, which gives the same dep list. Anyway, removing the .la file 'fixes' the problem, but well ...
Re: [pacman-dev] SyncFirst and dependencies
On Fri, Mar 18, 2011 at 12:55 PM, Lukas Fleischer archli...@cryptocrack.de wrote: Hi, I'm not really sure if this actually is a bug or intended behaviour but upgrading pacman man my freshly installed system with [testing] enabled just broke pacman: $ pacman pacman: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory After some investigation, I figured out that liblzma.so is part of xz-utils which was renamed to xz sometime ago. When doing the first full system upgrade, pacman asked me to upgrade itself, first. As SyncFirst packages seem to be pulled in without dependency resolution, I ended up in having pacman 3.5.0, but an old xz-utils, resulting in some broken pacman depending on some shared library of a package that hasn't been upgraded yet. Is that intended? Unfortunately, I'm in a rush and I don't have any time to analyze this in detail right now... dep resolution is done, but if the deps are not precise enough, it does not help. Another example where sodeps could have been useful :) As far as I can see, libarchive 2.8.4-2 got a versioned dep on xz = 5 but pacman only depends on libarchive 2.8.0
[pacman-dev] [PATCH] libalpm/diskspace.c: remove bogus parenthesis
---
lib/libalpm/diskspace.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/diskspace.c b/lib/libalpm/diskspace.c
index 253e118..bfc63e7 100644
--- a/lib/libalpm/diskspace.c
+++ b/lib/libalpm/diskspace.c
@@ -323,7 +323,7 @@ int _alpm_check_diskspace(pmtrans_t *trans, pmdb_t
*db_local)
(unsigned long)data-fsp.f_bfree);
if(data-max_blocks_needed + cushion = 0
(unsigned long)(data-max_blocks_needed + cushion)
data-fsp.f_bfree) {
- _alpm_log(PM_LOG_ERROR, _(Partition %s too
full: %ld blocks needed, %ld blocks free)\n),
+ _alpm_log(PM_LOG_ERROR, _(Partition %s too
full: %ld blocks needed, %ld blocks free\n),
data-mount_dir,
data-max_blocks_needed + cushion,
(unsigned
long)data-fsp.f_bfree);
abort = 1;
--
1.7.4.1
Re: [pacman-dev] [PATCH] Fix double close of the lock file
On Sat, Feb 5, 2011 at 1:39 AM, Jonathan Conder jonno.con...@gmail.com wrote: According to FOPEN(3), using fclose on an fdopen'd file stream also closes the underlying file descriptor. This happened in _alpm_lckmk (util.c), which meant that when alpm_trans_release closed it again, the log file (which reused the original file descriptor) was closed instead. Signed-off-by: Jonathan Conder jonno.con...@gmail.com --- So no one ever spotted this because logs are only made during a transaction ? Anyway nice finding :) Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
Re: [pacman-dev] Removing empty directories
On Sun, Feb 27, 2011 at 1:37 AM, Allan McRae al...@archlinux.org wrote: I just noticed this: pacman -Qk | grep ^warning warning: filesystem: /opt/ (No such file or directory) warning: hal: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hal-info: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hicolor-icon-theme: /usr/share/icons/hicolor/256x256/apps/ (No such file or directory) warning: network-manager-applet: /etc/gconf/schemas/ (No such file or directory) All these directories are empty in their package. They appear to have been removed when I uninstalled a different package that had files in that directory. Maybe we need some more checking before removing an empty directory. Allan http://mailman.archlinux.org/pipermail/pacman-dev/2009-July/009008.html https://bugs.archlinux.org/task/15668 https://bugs.archlinux.org/task/11263
Re: [pacman-dev] Removing empty directories
On Sun, Feb 27, 2011 at 11:53 AM, Allan McRae al...@archlinux.org wrote: I had a fair suspicion this had been discussed before... I just did a wtf? when I saw /opt had disappeared. I'm going to create a pactest for this. If we believe the performance hit to fix this problem is not worth it, why not consider these packaging problems, and have all these packages install a .keep file ?
Re: [pacman-dev] Removing empty directories
On Sun, Feb 27, 2011 at 12:40 PM, Allan McRae al...@archlinux.org wrote: How much of a performance hit would there really be? If I have this right in my head (big assumption), the file-lists for all packages are read in in one go. So all that we would have to do is loop over them checking for the empty directory before we add it to the removal list. Should be a minimal impact maybe... I suppose the best way is to make a patch and see! AFAIK the file lists currently do not need to be loaded with -R, so the impact would be loading them more than the checking itself. Then again, we have that cost for all -S operation already, so why not make -R as bad ? :) Anyway we will keep having problems until we have a single file for the local db as well.
Re: [pacman-dev] Style questions and concerns
On Fri, Feb 25, 2011 at 5:27 PM, Dan McGee dpmc...@gmail.com wrote:
I've noticed these things a lot in recent patches, so let the
discussion commence.
1) typedef-ed structs. This is just a copy the rest of them habit,
but I really feel we should stop doing this, only typedef-ing when we
are making a public-facing type that we don't want to expose the
internal contents of. Everything else should remain a struct type, and
referred to as such, no typedef and no confusion that the fields are
accessible.
Currently we have a lot of the following :
private header : struct __foo_t { ... }
public header : typedef struct __foo_t foo_t
Of course that only makes sense to hide internal contents of public types.
In the other cases, we should just have :
typedef struct foo_t { ... } foo_t ;
and this can be either in a public or in a private header, depending
if it's a fully public or fully private struct.
IE I don't think the typedef is the problem here, the typedef is good
and avoids writing struct everywhere.
3) C99. Several patches are introducing things that go further down
this road. I don't think they should all be avoided but I'm not sure
GCC 3.X (Cygwin is still on this?) supports all of these.
I am confused. So all these features are c99, but gcc 3.x only has a
partial c99 support ?
* Variable declarations not at the start of a block. I'm not a huge
fan of this, as I think having them at the start of the block helps
clarify scope a lot better.
I agree, it sucks. What's cool is variable decl in loop.
* Dynamically sized array declarations, e.g. data[numcpus]. I think
this needs to be avoided, unfortunately, but it isn't hard to just use
MALLOC/FREE in this case.
* C99 structure initialization (saw it in the parallelize patches).
Well we are in 2011, maybe it's time to start using features from the
previous Millennium.
At least it's still C for the nostalgic dinosaur.
Re: [pacman-dev] [PATCH 6/6] New VerbosePkgLists option
On Mon, Feb 21, 2011 at 8:02 PM, Jakob Gruber jakob.gru...@gmail.com wrote: If enabled, displays package lists for upgrade, sync and remove operations formatted as a table. Falls back to default list display if insufficient terminal columns are available. Example output (-Su): Targets (25): Pkg Name New Version Old Version Size asciidoc 8.6.4-1 8.6.3-1 0.15 MB chromium 9.0.597.94-2 9.0.597.94-1 17.80 MB ... wine 1.3.14-1 1.3.13-2 24.67 MB What about switching New and Old ? I've been using that new display for my last upgrades, and that order always confuses me, it would look more natural the other way around.
Re: [pacman-dev] License for new contributions?
On Sat, Feb 26, 2011 at 6:42 PM, edmeiste...@hushmail.com wrote: Hello pacman team! I've been following development for quite some time, and would like to submit my package signing patches for review. Out of curiosity, what do these patches accomplish exactly ? However, since some of the files are entirely new, they would have a license header. I would like to know under what license should I release my work. I bring this up because during this time I overlooked the inclusion of the rankmirrors script, which I've now noticed to be GPL v3 code. Should my files be GPL v2 or v3? Why don't you use the same header that all C files in pacman have, which is gpl v2 or later ?
Re: [pacman-dev] DRAFT: API changes for pacman-3.5
On Mon, Feb 7, 2011 at 4:58 AM, Allan McRae al...@archlinux.org wrote: This is a draft for the README file update for pacman-3.5. I have flagged two areas that I am not particularly clear at what happened. I would be great if the people involved in those changes could make the appropriate adjustments. I am afraid that would be me. ## HELP!!! - these changes... -int alpm_sync_target(char *target); -int alpm_sync_dbtarget(char *db, char *target); -int alpm_add_target(char *target); -int alpm_remove_target(char *target); +int alpm_add_pkg(pmpkg_t *pkg); +int alpm_remove_pkg(pmpkg_t *pkg); - the interface to add/remove targets was changed to take pmpkg_t rather than char * which was ambiguous. alpm_sync_target(char *target) and alpm_sync_dbtarget(char *db, char *target) are replaced by alpm_add_pkg(pmpkg_t *pkg). Packages can come from alpm_db_get_pkg (for normal targets), alpm_find_dbs_satisfier (for versioned provisions) or alpm_find_grp_pkgs (for groups). alpm_add_target(char *target) is replaced by alpm_pkg_load + alpm_add_pkg. alpm_remove_target is replaced by alpm_remove_pkg(pmpkg_t *pkg), with packages coming from alpm_db_get_pkg(db_local, target) or alpm_db_readgrp(db_local, target) + alpm_grp_get_pkgs(grp). ## HELP!!! - alpm_deptest() is replaced by the more flexibile alpm_find_satisfier() -int alpm_depcmp(pmpkg_t *pkg, pmdepend_t *dep); alpm_list_t *alpm_checkdeps(alpm_list_t *pkglist, int reversedeps, alpm_list_t *remove, alpm_list_t *upgrade); -alpm_list_t *alpm_deptest(pmdb_t *db, alpm_list_t *targets); +pmpkg_t *alpm_find_satisfier(alpm_list_t *pkgs, const char *depstring); +pmpkg_t *alpm_find_dbs_satisfier(alpm_list_t *dbs, const char *depstring); - alpm_deptest() is replaced by the more flexible alpm_find_satisfier() - alpm_depcmp(pmpkg_t *pkg, pmdepend_t *dep) was removed because the low levels function dealing with pmdepend_t (splitdep and depfree come to mind) are not exposed, which makes depcmp useless to a frontend. (I mentioned alpm_find_dbs_satisfier above in the target change)
Re: [pacman-dev] [ Package Signing ] Your signature please
On Sat, Feb 19, 2011 at 2:06 PM, IgnorantGuru jgj7.pacman...@mailnull.com wrote: Interesting that you think so, because patches are the way to make non-secure junk. The way to make things work is for the person most familiar with the code and protocols to make those changes rather than him begging others to write ill-fitting patches. Patches are also a big waste of time because what someone familiar with the code can do in a few minutes (and do well) may take hours of research for someone unfamiliar (to do poorly). Talk about efficiency - try applying it to your work in larger ways. Maybe that's one reason why it takes you so long to develop - you're unwilling to take on responsibility for the project as a whole. You definitely seem a very reluctant and whining freeware developer. Get over yourself and put some quality into your work, regardless of what you're paid or not paid. Or don't - in which case you're not worth your complaining. What makes you worth ? You are not only complaining, you are also freely attacking people when you have no idea who they are, what they do, and how things work around here. Ah, the joy of internet. I don't know why you felt the need to write so many mails just to say one thing : it would be nice to have signatures on the mirrors already, regardless of what pacman and repo-add support. And well, we agree, so thanks for your quality contribution !
Re: [pacman-dev] Version specs in replaces
On Fri, Feb 18, 2011 at 9:08 PM, Dan McGee dpmc...@gmail.com wrote: On Thursday, February 17, 2011, Daenyth Blank daenyth+a...@gmail.com wrote: On Thu, Feb 17, 2011 at 06:00, Allan McRae al...@archlinux.org wrote: On 17/02/11 10:42, Dan McGee wrote: So the first command makes sense, and at least right now we parse conflicts like we do depends- we allow version specifiers. However, I found the oddity with REPLACES when doing some archweb work tonight. Should we be allowing this? Should it be restricted to '=' only like provides? I'm not sure, so please chime in. I am struggling to think of any case where it would be appropriate to have a version in a replaces entry. Allan I ran into this the other day. An example would be python-yaml in community. Currently it's for python 2. I'm going to switch it so that there's a python2-yaml package and python-yaml would be python3. It would make sense for python2-yaml to REPLACES=(python-yaml$py3k_version) Any other input from anyone before Allan and I lock the definition down, and then make the code work appropriately? Versioned replace sounds good to me, and Daenyth provided an example.
Re: [pacman-dev] 3.5.0 release planning
On Tue, Feb 1, 2011 at 7:36 AM, Xyne x...@archlinux.ca wrote: Dan McGee wrote: * Allan's pkghash branch and work. This should be good to go, we were just sorting out a few lingering issues. Does that include the move to parsing sync database archives without extraction? No. This was a list of blocker, and reading tar sync archive is not one, it is ready for a while now. https://wiki.archlinux.org/index.php/Pacman_Roadmap Tar-based sync databases, split local and sync database code, more efficient local database
Re: [pacman-dev] sodeps: makepkg patches
On Tue, Feb 1, 2011 at 3:53 AM, Dan McGee dpmc...@gmail.com wrote:
I have the feeling this has been hashed/rehashed/blended before, but
why aren't we just doing something like:
provides=('myenv')
libprovides=('libx.so' 'liby.so')
To me, this seems a lot clearer and alleviates the black magic
concerns of changing depends/provides arrays on the fly.
I got confused by 'myenv', its supposed to be a normal provision like 'cron' ?
Anyway libprovides sounds fine to me, but the question is where do we
propagate this distinction, because there is no difference for pacman.
Should there also be a libprovides in PKGINFO and %LIBPROVIDES% in db,
and pacman will just read these two and merge them with provides ?
Or can they both be merged at the PKGINFO level ?
Re: [pacman-dev] [PATCH] Remove need to explicitly register the local DB
On Sat, Jan 29, 2011 at 10:09 AM, Xyne x...@archlinux.ca wrote: Even if it is negligible, it's munging separate logic together. Given that the purpose is presumably to save coders a few lines of code, I still think it would make more sense to use a wrapper function to do that when getting the handle. It's not separate logic. Dan commit log might have been a bit misleading. alpm_initialize initializes (wow) whatever is needed for the other functions to work. What we do there is just allocate some structures like the handle, and now handle-db_local as well. We are talking about one calloc and one strdup here to setup db_local. Really no big deal, there is no loading of the db, not even a check that one exists at all. And it does make it simpler for libalpm users. And as Dan said its symetric with alpm_release.
[pacman-dev] [PATCH] Makefile: Use git describe --dirty for GIT VERSION
dirty indicates if the repo has uncommited changes or not when building, so dont hardcode this info. Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- doc/Makefile.am|2 +- scripts/Makefile.am|2 +- src/pacman/Makefile.am |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/Makefile.am b/doc/Makefile.am index 6405cf0..37dab13 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -60,7 +60,7 @@ dist-hook: $(MAKE) $(AM_MAKEFLAGS) all if USE_GIT_VERSION -GIT_VERSION := $(shell sh -c 'git describe --abbrev=4 | sed s/^v//')-dirty +GIT_VERSION := $(shell sh -c 'git describe --abbrev=4 --dirty | sed s/^v//') REAL_PACKAGE_VERSION = $(GIT_VERSION) else REAL_PACKAGE_VERSION = $(PACKAGE_VERSION) diff --git a/scripts/Makefile.am b/scripts/Makefile.am index 2962b91..ae6ce36 100644 --- a/scripts/Makefile.am +++ b/scripts/Makefile.am @@ -25,7 +25,7 @@ EXTRA_DIST = \ MOSTLYCLEANFILES = $(bin_SCRIPTS) *.tmp if USE_GIT_VERSION -GIT_VERSION := $(shell sh -c 'git describe --abbrev=4 | sed s/^v//')-dirty +GIT_VERSION := $(shell sh -c 'git describe --abbrev=4 --dirty | sed s/^v//') REAL_PACKAGE_VERSION = $(GIT_VERSION) else REAL_PACKAGE_VERSION = $(PACKAGE_VERSION) diff --git a/src/pacman/Makefile.am b/src/pacman/Makefile.am index 8c14562..31e8b13 100644 --- a/src/pacman/Makefile.am +++ b/src/pacman/Makefile.am @@ -18,7 +18,7 @@ INCLUDES = -I$(top_srcdir)/lib/libalpm AM_CFLAGS = -pedantic -D_GNU_SOURCE if USE_GIT_VERSION -GIT_VERSION := $(shell sh -c 'git describe --abbrev=4 | sed s/^v//')-dirty +GIT_VERSION := $(shell sh -c 'git describe --abbrev=4 --dirty | sed s/^v//') DEFS += -DGIT_VERSION=\$(GIT_VERSION)\ endif -- 1.7.3.5
Re: [pacman-dev] [PATCH] Add interactive provider selection
On Fri, Nov 5, 2010 at 4:55 AM, Allan McRae al...@archlinux.org wrote: I think that if we are providing a selection dialog for provides then it should present packages from all repos to choose from. Otherwise it seems a half feature to me. So my working branch provides a full feature now ! Mostly first patch : Add interactive provider selection and next to last : select_display: per-database output
Re: [pacman-dev] [PATCH] Add interactive provider selection
On Sun, Jan 23, 2011 at 2:39 AM, Allan McRae al...@archlinux.org wrote: Awesome! Incredibly minor and pedantic points... The blank line between the final line of providers and Which one do you want to install? is not there when selecting members of a group: e.g. 53) udev 54) usbutils 55) util-linux-ng 56) vi 57) wget 58) which 59) wpa_supplicant 60) xfsprogs Which ones do you want to install? Enter a selection (default=all): That should be made consistent. done Also, perhaps change the one to package in the messages: done Which ones do you want to install? to: Which packages do you want to install? done
Re: [pacman-dev] when upgrading display versions
On Thu, Jan 20, 2011 at 8:17 PM, Divan Santana di...@s-tainment.co.za wrote: On Thursday 20 January 2011 19:39:18 Dan McGee wrote: You mean like this? https://bugs.archlinux.org/task/15772 Darn it... I should have seen that! I obviously didn't search thorough enough. I have always wanted that feature, so patches are very welcome :)
Re: [pacman-dev] [PATCH 2/5] alpm/depcmp: new NODEPVERSION flag
On Wed, Jan 19, 2011 at 7:57 PM, Dan McGee dpmc...@gmail.com wrote: On Wed, Jan 19, 2011 at 11:13 AM, Florian Pritz bluew...@xssn.at wrote: From: Xavier Chantry chantry.xav...@gmail.com This flag allows to disable version checking in dependency resolving code. depcmp_tolerant respects the NODEPVERSION flag but we still keep the original strict depcmp. The idea is to reduce the impact of the NODEPVERSION flag by using it in fewer places. I replaced almost all depcmp calls by depcmp_tolerant in deps.c (except in the public find_satisfier used by deptest / pacman -T), but I kept depcmp in sync.c and conflict.c Seems mostly OK, but without digging in I don't really understand why some get changed and some do not. Reading this again, the choice in find_satisfier probably does not matter, since I doubt pacman -T specifies NODEPVERSION. And if it could, well why not. So that one could be changed. Otherwise, the problem is that we use depcmp both for dep checking and conflict checking. We (Nagy, me) thought that nodepversion should only appy to versioned dep, and not versioned conflict, which are separate. But to be honest, I am not sure what's best. IIRC it's Nagy who first mentioned he did not like that nodepversion had an effect on all depcmp usage in the first version of the patch.
Re: [pacman-dev] [GIT] The official pacman repository annotated tag, v3.4.2, created. v3.4.2
On Thu, Dec 30, 2010 at 4:20 PM, Dan McGee dpmc...@gmail.com wrote: Speaking up about this now? I thought I've asked everyone if there was more for 3.4.2 at least a few times in the last few weeks... I'll take a look at Jakob's patches for maint. I thought I did but I couldn't find any proof. That said, I could not find any trace of a discussion about 3.4.2 either. The only thing I could see is that this bug was already targeted for 3.4.1 (for which I did find a mail on the ML) but it somehow passed through. And then I set the bug target to 3.4.2 so that it would appear in the roadmap and I hoped it would not be forgotten that way :) Anyway glad to see it's all fixed in maint now, so I will just pray for a quick 3.4.3 release ! If there is anything I can do, I would be happy to help.
Re: [pacman-dev] [PATCH] Declare all local functions static
On Sun, Dec 19, 2010 at 2:31 AM, Allan McRae al...@archlinux.org wrote: be_local.c:70:13: warning: no previous prototype for '_cache_get_filename' [-Wmissing-prototypes] -Wmissing-prototypes aims to detect global functions that fail to be declared in header files. Given we probably do not want to declare those in a header file and they are restricted to that one translation unit, I figured they should all be declared static... Just a side note: once you have gotten pacman fully compliant against a gcc option like this one, maybe it could be added to the Makefile so that we could spot all these small problems during dev ?
Re: [pacman-dev] [PATCH 2/2] Overhaul archive fgets function
On Wed, Dec 15, 2010 at 7:48 AM, Dan McGee d...@archlinux.org wrote: The old function was written in a time before we relied on it for nearly every operation. Since then, we have switched to the archive backend and now fast parsing is a big deal. The former function made a per-character call to the libarchive archive_read_data() function, which resulted in some 21 million calls in a typical load all sync dbs operation. If we instead do some buffering of our own and read the blocks directly, and then find our newlines from there, we can cut out the multiple layers of overhead and go from archive to parsed data much quicker. Both users of the former function are switched over to the new signature, made easier by the macros now in place in the sync backend parsing code. Performance: for a `pacman -Su` (no upgrades available), _alpm_archive_fgets() goes from being 29% of the total time to 12% The time spent on the libarchive function being called dropped from 24% to 6%. This pushes _alpm_pkg_find back to the title of slowest low-level function. Signed-off-by: Dan McGee d...@archlinux.org --- I wish this one was a bit easier to comprehend and grok, but the cost of performance here is a bit more complicated fgets function than the very simplistic one we had before. The new function revolves around the zero-copy, retrieve an entire block functinoality of libarchive. We create a structure to keep all the bookkeeping info we need around, including a buffer of our own where each line ends up and auto-resizes itself as we poll through an archive file entry, and also cleans itself up when the file is EOF. This means malloc/free is not necessary by the caller, which keeps most concerns in the fgets function. Please let me know if it is unclear how the new function works, so more comments can be put in there. Since we have just one line, I would not have bothered trying to alloc exactly what we need. I would just have used a static or dynamic buf of max line size, and be done with it. But anyway you already implemented the more complex way and I don't see a problem with that as long as its tested (especially the re-alloc part) :) I could not spot a problem by simply reading the code. Another minor observation : in the !done case, the alloc block does a strict allocation and thus does not take into account that we will very likely have to extend it on the next iteration (if we did not reach the last archive block). Finally can it actually happen with our sync archives which only has very small files that a line is split across two blocks ? In any cases, this is another very welcome improvement.
Re: [pacman-dev] [PATCH 0/4] Package list find performance improvements
On Tue, Dec 14, 2010 at 7:46 PM, Dan McGee d...@archlinux.org wrote: This series of patches makes finding a package in our linked list implementation a whole lot faster, if that search is using the standard _alpm_pkg_find, which nearly all are (after the first patch). It does this by adding a hash function to util.c which is nothing too complicated and named after a publicly available algorithm. When packages are created, we fill in this hash value as soon as the pkgname is read. Finally, the _alpm_pkg_find function is rewritten to take advantage of this field, avoiding repeated strcmp() calls and only falling back to that if a hash is not available and to verify the hash value was not some sort of collision. Performance figures and numbers are available in the last patch. This actually speeds up operations by nearly 33%, so this is not a total waste of time to consider. :) Review and questions/comments/concerns welcome! That's nice and short :) -Dan Dan McGee (4): Use _alpm_pkg_find in deps search Add hash_sdbm function When setting package name, set hash value as well Used hashed package name in _alpm_pkg_find lib/libalpm/be_package.c | 1 + lib/libalpm/deps.c | 4 ++-- lib/libalpm/package.c | 16 ++-- lib/libalpm/package.h | 1 + lib/libalpm/util.c | 22 ++ lib/libalpm/util.h | 1 + 6 files changed, 41 insertions(+), 4 deletions(-) -- 1.7.3.3
Re: [pacman-dev] Warning to pacman-git users - database format change
On Mon, Dec 13, 2010 at 5:19 AM, Allan McRae al...@archlinux.org wrote: Pacman's local database format changes with this commit being pushed to master: commit 21833d90e26635fdd2c6af247790a9bf374b4d80 Author: Allan McRae al...@archlinux.org Date: Sat Oct 30 15:35:43 2010 +1000 Merge desc and depends files in local db If you want to run pacman-git you will need to upgrade your pacman database format using the conviently named pacman-db-upgrade script in the scripts/ directory. This is not a particularly reversible operation, so if you run this you are stuck with pacman-git until the 3.5 release. It probably should backup the old database if it doesn't already :) cd /var/lib/pacman/ ; tar cvzf pacman-localdb.tar.gz local/ or whatever. Maybe not in /var/lib/pacman if this is cleaned up by pacman -Sc , after all.
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.
Re: [pacman-dev] Disk space checking branch complete
On Wed, Nov 17, 2010 at 1:06 AM, Dan McGee dpmc...@gmail.com wrote: We've putzed around with this a few times, haven't we? This basically reverts this one: commit 149839c5391e9a93465f86dbb8d095a0150d755d Author: Xavier Chantry shinin...@gmail.com Date: Mon May 26 23:46:01 2008 +0200 du -b is not available on BSD, use du -k instead. This fixes FS#10459. There is apparently no portable ways to get the apparent size of a file, like du -b does. So the best compromise seems to get the block size in kB, and then convert that to byte so that we keep compatibility. Signed-off-by: Xavier Chantry shinin...@gmail.com Signed-off-by: Dan McGee d...@archlinux.org It doesn't revert my commit, it just takes the alternative approach which was already suggested in the bug report : https://bugs.archlinux.org/task/10459#comment28616 We do this already for stat and sed, we do this in C (c.f. diskspace), so why not for du ? I've no problem with that. That said, I've no problem with a C impl either. Would it be portable ? Just wanted to mention that even though I wrote this patch, I am for restoring apparent size. IIRC we already got a report/request for that a while ago and I already felt that way back then.
Re: [pacman-dev] [PATCH] Warn when synchronizing without upgrading (-Sy)
On Wed, Nov 17, 2010 at 10:00 PM, Thomas Bahn thomas-b...@gmx.net wrote: this patch introduces a question on every repository sync if a am right. So that patch also asks if you type 'pacman -Syu' ? If it is i would not vote for this patch, because it's another question you must acknoweledge every system update. If it only asks on 'pacman -Sy package' then its ok for me. Another suggestion, only print this warning and don't ask. An arch user would read the output of pacman and its package pre/post-scripts and is warned. AFAI can see, it only asks for -Sy and -Sy targets
Re: [pacman-dev] Versioned packages on the command line.
On Thu, Nov 11, 2010 at 8:46 PM, Xyne x...@archlinux.ca wrote: Hi, If two repos (obviously not both official) provide the same binary package, pacman will install the package from the repo that is listed first in pacman.conf, if specified on the command line, e.g. pacman -S foo. If another package depends on foo, the same thing happens, but if it instead depends on foo=1.4 and only the second repo provides it, then pacman will correctly skip over the first repo and install it from the second. If so, would you consider making it possible to specify versions directly on the command line, e.g. pacman -S foo=1.4. I know that it's possible to first do a search for the package to see which repos contain it, then prepend the repo, e.g. pacman -S second-repo/foo, but it would be more useful sometimes to be able to just specify the version using =, =, etc. This would ideally also work for detecting providers too, e.g. if bar provides foo=1.4 then pacman -S foo=1.4 would install bar (or bring up the provider selection dialogue once that's included... I really like that idea btw... considered doing that in powerpill at some point) For a possible use of this, see the following post on the arch-haskell mailing list: http://www.haskell.org/pipermail/arch-haskell/2010-November/000740.html Did you actually try it ?
Re: [pacman-dev] [RFC] New member selection when installing group
On Thu, Nov 4, 2010 at 10:53 AM, Allan McRae al...@archlinux.org wrote: My general impression of this is that it is really, really good and a great improvement over what we have now or had in the past. Here are relatively minor comments: The Enter a number selection prompt is a bit weirdly worded when using e.g. 1-10 ^8. Maybe Enter selection instead? That sounds better. If the selected 1 output is to stay (is it?), it should maybe say selected pkg instead? Also, using 1-10 ^8 says selected 8... unselected 8. If that output is to say, I guess that should just say unselected 8 maybe? This was just meant to be a debug output for early testing / experimenting. I wanted to kill it if the idea was accepted. Doing a pacman -S base --needed processes the --needed after the selection dialog which is annoying... is that easily changed? It does not matter if not. Ah uhm right. Here is how it works now : 1) alpm_find_grp_pkgs gives to the frontend a list of sync packages, members of a specified group 2) interactive selection in frontend 3) alpm_add_pkg called on each package, where the --needed check is done (this means checking for existing local package and comparing versions) It's definitely possible to add needed check in the backend in 1) or in the frontend just before 2). Not sure where it would fit, I will let others decide that and I can then implement it if needed (no pun intended).
Re: [pacman-dev] [PATCH] Add interactive provider selection
On Thu, Nov 4, 2010 at 11:00 AM, Allan McRae al...@archlinux.org wrote: On 20/10/10 05:10, Xavier Chantry wrote: If there are multiple providers in one db, pacman used to just stop at the first one (both during dependency resolution or for pacman -S 'provision' which uses the same code). I like the idea, but does this not work cross repos? That's indeed what I tried to describe above. I hesitated on this point, but finally I thought this behavior was more consistent with normal target (literal) lookup or group members lookup in the db. It's always the first repo that has the priority and others are ignored. It should not be hard to change the behavior of _alpm_resolvedep though.
Re: [pacman-dev] some pacman work
On Wed, Oct 20, 2010 at 6:54 AM, Allan McRae al...@archlinux.org wrote: pactree: all the work I did with Dave Reisner on pactree C rewrite, all ready and done now. depends on depwork for find_satisfier Cool. Still not sure about moving it to util instead of contrib. It does not really fit in with vercmp, testdb etc which are distributed by make install. It was more a technical than a logical separation. It was easy to add pactree C in src/util next to all the other alpm based C programs. 1) it helps to look at the existing C standalone progs to start a new one 2) the Makefile / .gitignore is easy to extend These two arguments probably apply to having scripts in contrib/ directory. I don't know how to best deal with this technical separation and the more logical one (utils shipped by make install vs contrib stuff).
Re: [pacman-dev] [PATCH] Add function to list mount points
On Sun, Oct 31, 2010 at 2:58 PM, Allan McRae al...@archlinux.org wrote: On 31/10/10 22:53, Allan McRae wrote: The helper function _alpm_mount_list provides a relatively portable interface to obtaining a list of mount pints on a system. This will be useful in checking for disk space availability when installing packages. Signed-off-by: Allan McRaeal...@archlinux.org --- I have not tested the HAVE_GETMNTINFO path as that requires BSD4.4, OSX or NetBSD 3.0. However, it is taken from various example code on the internet so should work... A slightly updated version following comments by Xavier is on my working branch (http://projects.archlinux.org/users/allan/pacman.git/log/?h=working). Allan If we agree on the #if defined .. #elif defined .. #endif , we should probably do it for the includes too.
Re: [pacman-dev] [PATCH] Sync data after writing to the local db
On Sat, Oct 30, 2010 at 3:01 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote: Wouldn't this cause a notable slow-down? I thought the issue was rather that the local db entries would be synced when the actual package files are probably not synced. But if we sync everything, then it's very likely to become very slow. I seem to remember that Dan sent a fdatasync patch a while ago, I don't remember if it affected only the db or both db and files. Also let's not forget this : Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
Re: [pacman-dev] epoch (was: Chat with toofis...@jabber.org)
On Mon, Oct 25, 2010 at 1:03 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote: Nagy and I discussed a bit that topic. Don't we already read all local depends file for conflict and/or dep checking ? So this means we'll now read all local depends + all desc files ? Why not put epoch stuff in the local depends file then ? IIRC there has been a plan for years to move replaces and force from depends to desc, probably for sync db? and for similar reasons, but no one ever dared to do it. Another crazy thought, since epoch is really just a version extension, why not define it as a version prefix or something ? 3.5.0 2#3.4 3#2.0 or whatever crazy syntax we can come up with. Then we just need to have vercmp support that, and that's all, nothing complex to do in any database. I prefer this tricky solution. Logically, epoch is an extension of the version number, so this doesn't even seem too hackish. And I would completely drop %FORCE% without backward compatibility to eliminate the need for reading db to get epoch. When %FORCE% doesn't work, pacman just won't upgrade some packages with -Su, and since our crucial packages (pacman, glibc etc.) has no force and versioned dependencies are used, this is not a big deal. Of course, in arch news this force-epoch change should be mentioned (to AUR packagers). Alternative solution: db rewrite. ;-) Not really a problem, but just wanted to mention something I just spotted in today -Su. xpdf had force flag, and was installed with pacman-epoch so local db entry had EPOCH=1 Now the versions were sane enough, so xpdf update dropped the force flag : http://repos.archlinux.org/wsvn/packages?op=compcompare[]=/xpdf/tr...@58377compare[]=/xpdf/tr...@9 This works just fine with pacman 3.4 but not with pacman-epoch. :: Starting full system upgrade... warning: xpdf: local (3.02_pl4-2) is newer than extra (3.02_pl5-1)
Re: [pacman-dev] epoch
On Sat, Oct 30, 2010 at 11:26 PM, Allan McRae al...@archlinux.org wrote: That is because none of the packages know about epoch yet. You are going to have to manually update packages that use the force flag for the time being. BTW, the db update in [testing] has epoch=1 as the db-4.9 package had a force value, so you should be able to update that. Since force is simply interpreted as epoch=1, sane version bumps of force packages should work (as was the case with xpdf). But now that you point it out, insane version changes would not work indeed, that's the ones which would require an epoch bump. Anyway I was just pointing out that when a package has epoch=1, it can not be dropped. Which implies that force cannot be dropped, but only kept or replaced by epoch=1 or higher.
Re: [pacman-dev] [RFC] New member selection when installing group
On Wed, Oct 20, 2010 at 8:27 PM, Florian Pritz bluew...@server-speed.net wrote: Yaourt doesn't have this feature for groups (sadly), but for -Syu. You can use the editor to select which packages you want to upgrade and with ones you want to ignore. I just meant you can do the same thing for groups, but it looks like my hint was to subtle ;) Damn, sorry, I just cannot read these days. So why doesn't yaourt do it for groups, I would think the same code could be shared for both cases.
Re: [pacman-dev] some pacman work
About my pending work on http://code.toofishes.net/cgit/xavier/pacman.git/ parseargs: sent to the ML and updated according to feedback depwork: forgot if I send this stuff, should I ? pactree: all the work I did with Dave Reisner on pactree C rewrite, all ready and done now. depends on depwork for find_satisfier sodeps: depends on parseargs because it changes one arg, and on depwork (make depcmp private), because it changes many _alpm_depcmp to _alpm_depcmp_tolerant. This was sent to ML. Nagy said it was ok. I find this distinction between depcmp (ignore -Sdd) vs depcmp_tolerant (respect -Sdd) a bit ugly, but I don't see any better way. I am happy with parseargs, depwork, and pactree. One small worry about depwork and its alpm_find_satisfier function : the purpose of this function is kinda duplicated with alpm/dep: add alpm_find_dbs_satisfier I made in working. After writing alpm_find_dbs_satisfier, I thought I would kill alpm_find_satisfier, but both have different advantages, and slightly different purpose. alpm_find_satisfier is very simple : it just calls splitdep+_alpm_find_dep_satisfier, which are both very simple. It just answers this question : is there one satisfier for this dep in this package list ? Perfect for deptest / pacman -T, could be useful for other tools. alpm_find_dbs_satisfier: much more complex, but similar purpose. its goal is to answer : which satisfier would pacman choose for this dep in this list of sync dbs ? Less flexible than alpm_find_satisfier (cannot give any list of package, it has to be one or more db), much uglier and complex code. But it exposes exactly what pacman does to find a satisfier : - search literal in a first pass, provider in a second pass only if no literal - for both pass, it scans the list of sync dbs in order, and the first sync db has priority over the next ones - handles ignorepkg with a QUESTION IgnorePkg callback (but this can be disabled simply with no or empty conversation callback) - handle multiple provision with another QUESTION callback, but same as for ignorepkg I needed alpm_find_dbs_satisfier to migrate pacman frontend to the alpm_add_pkg(pmpkg_t *) interface. I decided to keep alpm_find_satisfier anyway for its simplicity. For the stuff on working, I probably need other mails to present it.
[pacman-dev] [PATCH] Add interactive provider selection
If there are multiple providers in one db, pacman used to just stop at
the first one (both during dependency resolution or for pacman -S
'provision' which uses the same code).
This adds a new conversation callback so that the user can choose which
provider to install. By default (user press enter or --noconfirm), the
first provider is still chosen, so for example the behavior of sync402
and 403 is preserved. But at least the user now has the possibility to
make the right choice in a manual run.
$ pacman -S community/smtp-server
:: There are 3 providers available for smtp-server:
1) courier-mta 2) esmtp 3) exim
Which one do you want to install?
Enter a number (default=1):
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
lib/libalpm/alpm.h|1 +
lib/libalpm/deps.c| 28 +-
src/pacman/callback.c | 13 ++
src/pacman/util.c | 61 +
src/pacman/util.h |2 +
5 files changed, 103 insertions(+), 2 deletions(-)
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index 237e235..d9e5439 100644
--- a/lib/libalpm/alpm.h
+++ b/lib/libalpm/alpm.h
@@ -379,6 +379,7 @@ typedef enum _pmtransconv_t {
PM_TRANS_CONV_CORRUPTED_PKG = (1 3),
PM_TRANS_CONV_LOCAL_NEWER = (1 4),
PM_TRANS_CONV_REMOVE_PKGS = (1 5),
+ PM_TRANS_CONV_SELECT_PROVIDER = (1 6),
} pmtransconv_t;
/* Transaction Progress */
diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c
index cdaf524..f94f16c 100644
--- a/lib/libalpm/deps.c
+++ b/lib/libalpm/deps.c
@@ -510,6 +510,10 @@ pmpkg_t *_alpm_resolvedep(pmdepend_t *dep, alpm_list_t
*dbs,
{
alpm_list_t *i, *j;
int ignored = 0;
+
+ alpm_list_t *providers = NULL;
+ int count;
+
/* 1. literals */
for(i = dbs; i; i = i-next) {
pmpkg_t *pkg = _alpm_db_get_pkgfromcache(i-data, dep-name);
@@ -549,11 +553,31 @@ pmpkg_t *_alpm_resolvedep(pmdepend_t *dep, alpm_list_t
*dbs,
continue;
}
}
- _alpm_log(PM_LOG_WARNING, _(provider package
was selected (%s provides %s)\n),
-pkg-name, dep-name);
+ _alpm_log(PM_LOG_DEBUG, provider found (%s
provides %s)\n,
+ pkg-name, dep-name);
+ providers = alpm_list_add(providers, pkg);
+ /* keep looking for other providers in the
current db */
+ }
+ }
+ /* if there is more than one provider, we ask the user */
+ count = alpm_list_count(providers);
+ if(count == 1) {
+ pmpkg_t *pkg =
alpm_list_getdata(alpm_list_first(providers));
+ alpm_list_free(providers);
+ return(pkg);
+ } else if(count 1) {
+ /* default to first provider if there is no QUESTION
callback */
+ int index = 0;
+ QUESTION(handle-trans, PM_TRANS_CONV_SELECT_PROVIDER,
+ providers, dep, NULL, index);
+ if(index = 0 index count) {
+ pmpkg_t *pkg =
alpm_list_getdata(alpm_list_nth(providers, index));
+ alpm_list_free(providers);
return(pkg);
}
}
+ alpm_list_free(providers);
+ providers = NULL;
}
if(ignored) { /* resolvedeps will override these */
pm_errno = PM_ERR_PKG_IGNORED;
diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index 32dafb5..f54fe4a 100644
--- a/src/pacman/callback.c
+++ b/src/pacman/callback.c
@@ -296,6 +296,19 @@ void cb_trans_conv(pmtransconv_t event, void *data1, void
*data2,
alpm_list_free(namelist);
}
break;
+ case PM_TRANS_CONV_SELECT_PROVIDER:
+ {
+ alpm_list_t *providers = (alpm_list_t *)data1;
+ int count = alpm_list_count(providers);
+ char *depstring =
alpm_dep_compute_string((pmdepend_t *)data2);
+ printf(_(:: There are %d providers available
for %s:\n), count,
+ depstring);
+ free(depstring);
+ select_display(providers);
+ printf(\n);
+ *response = select_question(count, _(Which one
do you want to install?));
+ }
+ break
Re: [pacman-dev] Chat with toofis...@jabber.org
On Fri, Oct 8, 2010 at 7:06 PM, toofis...@jabber.org toofis...@jabber.orgwrote: 5:48 PM me: waoh, where does this come from ? :) what made you implement epoch ? toofishes: the stupid bug reports clicked on one and went ok we have three of these lets fix this shit 5:49 PM it ended up not even being that much change, which was nice had to fix a few things after running tests and such, but overall pretty straightforward me: what was hard ? keep support for force ? 5:50 PM toofishes: yeah ensuring both forward/backward support 5:51 PM me: the result looks pretty good and natural toofishes: yeah and eventually some of it can be cleaned up can you spot the one drawback from this though? i didn't catch it at first, had to go back and fix my patch you will laugh because you were talking about it the other day. 5:52 PM me: give me a hint, is it pacman related or makepkg/repo-add toofishes: pacman database releated 5:56 PM me: damn I cannot see, looking at the patch in be_files.c . and last thing I remember discussing about database was sanity check. maybe bogus epoch values or something force was just on/off toofishes: no we didn't have to read every desc file before but now we do to always get the epoch value back 5:58 PM me: damn I actually spotted the vercmp call and force/epoch was in a different order but I just thought force definitely looked weird 5:59 PM ok I mentioned slow db too, I never considered this depends/desc thing really. nagy mentioned it many times though and I thought we were already fucked toofishes: yeah we just need to redo the db, tahts all :) Nagy and I discussed a bit that topic. Don't we already read all local depends file for conflict and/or dep checking ? So this means we'll now read all local depends + all desc files ? Why not put epoch stuff in the local depends file then ? IIRC there has been a plan for years to move replaces and force from depends to desc, probably for sync db? and for similar reasons, but no one ever dared to do it. Another crazy thought, since epoch is really just a version extension, why not define it as a version prefix or something ? 3.5.0 2#3.4 3#2.0 or whatever crazy syntax we can come up with. Then we just need to have vercmp support that, and that's all, nothing complex to do in any database. I am sorry this comes up a bit late, but only git code has been touched and no harm has been made as far as I know, I just want to be sure that we carefully considered all possible solutions for the stupid versioning some projects use, and that we indeed chose the best way (epoch is probably alright and better than force), but also the best implementation.
[pacman-dev] [PATCH] Sort short options before long options in --help
$ pacman -Uh
options:
-b, --dbpath path set an alternate database location
-d, --nodeps skip dependency checks
-f, --force force install, overwrite conflicting files
-k, --dbonly only modify database entries, not package files
-r, --root pathset an alternate installation root
-v, --verbosebe verbose
--arch archset an alternate architecture
--asdeps install packages as non-explicitly installed
--asexplicit install packages as explicitly installed
--cachedir dir set an alternate package cache location
--config path set an alternate configuration file
--debug display debug messages
--ignore pkg ignore a package upgrade (can be used more than once)
--ignoregroup grp
ignore a group upgrade (can be used more than once)
--logfile path set an alternate log file
--noconfirm do not ask for any confirmation
--noprogressbar do not show a progress bar when downloading files
--noscriptletdo not execute the install scriptlet if one exists
--print only print the targets instead of performing the
operation
--print-format string
specify how the targets should be printed
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/pacman/pacman.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index 7d51124..3bfe6ef 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -28,6 +28,7 @@
#include stdlib.h /* atoi */
#include stdio.h
+#include ctype.h /* isspace */
#include limits.h
#include getopt.h
#include string.h
@@ -59,6 +60,30 @@ pmdb_t *db_local;
/* list of targets specified on command line */
static alpm_list_t *pm_targets;
+/* Used to sort the options in --help */
+static int options_cmp(const void *p1, const void *p2)
+{
+ const char *s1 = p1;
+ const char *s2 = p2;
+ int ret = 0;
+
+ /* First skip all spaces in both strings */
+ while(isspace((unsigned char)*s1))
+ s1++;
+ while(isspace((unsigned char)*s2))
+ s2++;
+ /* If we compare a long option (--abcd) and a short one (-a),
+* the short one always wins */
+ if (*(s1+1) != '-' *(s2+1) == '-') {
+ ret = -1;
+ } else if (*(s2+1) != '-' *(s1+1) == '-') {
+ ret = 1;
+ } else {
+ ret = strcmp(s1, s2);
+ }
+ return(ret);
+}
+
/** Display usage/syntax for the specified operation.
* @param op the operation code requested
* @param myname basename(argv[0])
@@ -166,7 +191,7 @@ static void usage(int op, const char * const myname)
addlist(_( --logfile path set an alternate log
file\n));
addlist(_( --noconfirm do not ask for any
confirmation\n));
}
- list = alpm_list_msort(list, alpm_list_count(list), str_cmp);
+ list = alpm_list_msort(list, alpm_list_count(list), options_cmp);
for (i = list; i; i = alpm_list_next(i)) {
printf(%s, (char *)alpm_list_getdata(i));
}
--
1.7.3.1
[pacman-dev] [PATCH 1/3] add 4 pactests for -Sdd
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- test/pacman/tests/sync-sdd1.py | 18 ++ test/pacman/tests/sync-sdd2.py | 15 +++ test/pacman/tests/sync-sdd3.py | 15 +++ test/pacman/tests/sync-sdd4.py | 17 + 4 files changed, 65 insertions(+), 0 deletions(-) create mode 100644 test/pacman/tests/sync-sdd1.py create mode 100644 test/pacman/tests/sync-sdd2.py create mode 100644 test/pacman/tests/sync-sdd3.py create mode 100644 test/pacman/tests/sync-sdd4.py diff --git a/test/pacman/tests/sync-sdd1.py b/test/pacman/tests/sync-sdd1.py new file mode 100644 index 000..4438ef0 --- /dev/null +++ b/test/pacman/tests/sync-sdd1.py @@ -0,0 +1,18 @@ +self.description = -Sdd: -Sdd works + +p1 = pmpkg(pkg1, 1.0-2) +p1.depends = [provision1.0-1] +self.addpkg2db(sync, p1) + +p2 = pmpkg(pkg2, 1.0-2) +p2.provides = [provision=1.0-1] +self.addpkg2db(sync, p2) + +self.args = -Sdd %s % p1.name + +self.addrule(PACMAN_RETCODE=0) +self.addrule(PKG_EXIST=pkg1) +self.addrule(PKG_EXIST=pkg2) +self.addrule(PKG_DEPENDS=pkg1|provision1.0-1) + +self.expectfailure = True diff --git a/test/pacman/tests/sync-sdd2.py b/test/pacman/tests/sync-sdd2.py new file mode 100644 index 000..5f1f847 --- /dev/null +++ b/test/pacman/tests/sync-sdd2.py @@ -0,0 +1,15 @@ +self.description = -Sdd: -S fails + +p1 = pmpkg(pkg1, 1.0-2) +p1.depends = [provision=1.0-2] +self.addpkg2db(sync, p1) + +p2 = pmpkg(pkg2, 1.0-2) +p2.provides = [provision=1.0-1] +self.addpkg2db(sync, p2) + +self.args = -S %s % p1.name + +self.addrule(PACMAN_RETCODE=1) +self.addrule(!PKG_EXIST=pkg1) +self.addrule(!PKG_EXIST=pkg2) diff --git a/test/pacman/tests/sync-sdd3.py b/test/pacman/tests/sync-sdd3.py new file mode 100644 index 000..68733af --- /dev/null +++ b/test/pacman/tests/sync-sdd3.py @@ -0,0 +1,15 @@ +self.description = -Sdd: -Sd works but no deps + +p1 = pmpkg(pkg1, 1.0-2) +p1.depends = [provision=1.0-2] +self.addpkg2db(sync, p1) + +p2 = pmpkg(pkg2, 1.0-2) +p2.provides = [provision=1.0-1] +self.addpkg2db(sync, p2) + +self.args = -Sd %s % p1.name + +self.addrule(PACMAN_RETCODE=0) +self.addrule(PKG_EXIST=pkg1) +self.addrule(!PKG_EXIST=pkg2) diff --git a/test/pacman/tests/sync-sdd4.py b/test/pacman/tests/sync-sdd4.py new file mode 100644 index 000..4cd4b54 --- /dev/null +++ b/test/pacman/tests/sync-sdd4.py @@ -0,0 +1,17 @@ +self.description = -Sdd: provision does not exist + +p1 = pmpkg(pkg1, 1.0-2) +p1.depends = [invalid=1.0-2] +self.addpkg2db(sync, p1) + +p2 = pmpkg(pkg2, 1.0-2) +p2.provides = [provision=1.0-1] +self.addpkg2db(sync, p2) + +self.args = -Sdd %s % p1.name + +self.addrule(PACMAN_RETCODE=1) +self.addrule(!PKG_EXIST=pkg1) +self.addrule(!PKG_EXIST=pkg2) + +self.expectfailure = True -- 1.7.3.1
[pacman-dev] [PATCH 3/3] add -dd option
From: Florian Pritz bluew...@xssn.at
-dd ignores only the version of a dependency being checked, but not the
package itself.
Signed-off-by: Florian Pritz bluew...@xssn.at
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
doc/pacman.8.txt |1 +
src/pacman/pacman.c| 11 ++-
test/pacman/tests/sync-sdd1.py |2 --
test/pacman/tests/sync-sdd4.py |2 --
4 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt
index 2b47a88..735bff9 100644
--- a/doc/pacman.8.txt
+++ b/doc/pacman.8.txt
@@ -155,6 +155,7 @@ Transaction Options (apply to '-S', '-R' and '-U')
Skips all dependency checks. Normally, pacman will always check a
package's dependency fields to ensure that all dependencies are
installed and there are no package conflicts in the system.
+ Specify this option twice to skip the version checking only.
*-k, \--dbonly*::
Adds/Removes the database entry only, leaves all files in place.
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index 7d51124..d83ec07 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -512,8 +512,17 @@ static int parsearg_query(int opt)
/* options common to -S -R -U */
static int parsearg_trans(int opt)
{
+ static int nodeps = 0;
switch(opt) {
- case 'd': config-flags |= PM_TRANS_FLAG_NODEPS; break;
+ case 'd':
+ nodeps++;
+ if(nodeps == 1) {
+ config-flags |= PM_TRANS_FLAG_NODEPS;
+ } else if(nodeps == 2) {
+ config-flags ^= PM_TRANS_FLAG_NODEPS;
+ config-flags |= PM_TRANS_FLAG_NODEPVERSION;
+ }
+ break;
case 'k': config-flags |= PM_TRANS_FLAG_DBONLY; break;
case OP_NOPROGRESSBAR: config-noprogressbar = 1; break;
case OP_NOSCRIPTLET: config-flags |=
PM_TRANS_FLAG_NOSCRIPTLET; break;
diff --git a/test/pacman/tests/sync-sdd1.py b/test/pacman/tests/sync-sdd1.py
index 4438ef0..c73d203 100644
--- a/test/pacman/tests/sync-sdd1.py
+++ b/test/pacman/tests/sync-sdd1.py
@@ -14,5 +14,3 @@
self.addrule(PKG_EXIST=pkg1)
self.addrule(PKG_EXIST=pkg2)
self.addrule(PKG_DEPENDS=pkg1|provision1.0-1)
-
-self.expectfailure = True
diff --git a/test/pacman/tests/sync-sdd4.py b/test/pacman/tests/sync-sdd4.py
index 4cd4b54..c96c6df 100644
--- a/test/pacman/tests/sync-sdd4.py
+++ b/test/pacman/tests/sync-sdd4.py
@@ -13,5 +13,3 @@
self.addrule(PACMAN_RETCODE=1)
self.addrule(!PKG_EXIST=pkg1)
self.addrule(!PKG_EXIST=pkg2)
-
-self.expectfailure = True
--
1.7.3.1
Re: [pacman-dev] [PATCH] Sort short options before long options in --help
On Thu, Oct 14, 2010 at 1:55 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote:
I like this.
Cool :)
+ /* First skip all spaces in both strings */
+ while(isspace((unsigned char)*s1))
+ s1++;
+ while(isspace((unsigned char)*s2))
+ s2++;
+ /* If we compare a long option (--abcd) and a short one (-a),
+ * the short one always wins */
+ if (*(s1+1) != '-' *(s2+1) == '-') {
+ ret = -1;
I hope you don't pass invalid string arguments (e.g. empty string),
otherwise we can get a segfault here.
I missed something very important. I thought we had complete controls
on these strings, while in fact we don't have any control at all,
since it's the gettext-ed strings that I sort :P
I will make a safer version, thanks.
[pacman-dev] [PATCH] Sort short options before long options in --help
$ pacman -Uh
options:
-b, --dbpath path set an alternate database location
-d, --nodeps skip dependency checks
-f, --force force install, overwrite conflicting files
-k, --dbonly only modify database entries, not package files
-r, --root pathset an alternate installation root
-v, --verbosebe verbose
--arch archset an alternate architecture
--asdeps install packages as non-explicitly installed
--asexplicit install packages as explicitly installed
--cachedir dir set an alternate package cache location
--config path set an alternate configuration file
--debug display debug messages
--ignore pkg ignore a package upgrade (can be used more than once)
--ignoregroup grp
ignore a group upgrade (can be used more than once)
--logfile path set an alternate log file
--noconfirm do not ask for any confirmation
--noprogressbar do not show a progress bar when downloading files
--noscriptletdo not execute the install scriptlet if one exists
--print only print the targets instead of performing the
operation
--print-format string
specify how the targets should be printed
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/pacman/pacman.c | 39 ++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index 7d51124..38d7f6a 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -26,8 +26,10 @@
#define PACKAGE_VERSION GIT_VERSION
#endif
+#include assert.h
#include stdlib.h /* atoi */
#include stdio.h
+#include ctype.h /* isspace */
#include limits.h
#include getopt.h
#include string.h
@@ -59,6 +61,41 @@ pmdb_t *db_local;
/* list of targets specified on command line */
static alpm_list_t *pm_targets;
+/* Used to sort the options in --help */
+static int options_cmp(const void *p1, const void *p2)
+{
+ const char *s1 = p1;
+ const char *s2 = p2;
+
+ assert(s1);
+ assert(s2);
+ /* First skip all spaces in both strings */
+ while(isspace((unsigned char)*s1))
+ s1++;
+ while(isspace((unsigned char)*s2))
+ s2++;
+ /* If we compare a long option (--abcd) and a short one (-a),
+* the short one always wins */
+ if(*s1 == '-' *s2 == '-') {
+ s1++;
+ s2++;
+ if(*s1 == '-' *s2 == '-') {
+ /* two long - strcmp */
+ s1++;
+ s2++;
+ } else if(*s2 == '-') {
+ /* s1 short, s2 long */
+ return(-1);
+ } else if(*s1 == '-') {
+ /* s1 long, s2 short */
+ return(1);
+ }
+ /* two short - strcmp */
+ }
+
+ return(strcmp(s1, s2));
+}
+
/** Display usage/syntax for the specified operation.
* @param op the operation code requested
* @param myname basename(argv[0])
@@ -166,7 +203,7 @@ static void usage(int op, const char * const myname)
addlist(_( --logfile path set an alternate log
file\n));
addlist(_( --noconfirm do not ask for any
confirmation\n));
}
- list = alpm_list_msort(list, alpm_list_count(list), str_cmp);
+ list = alpm_list_msort(list, alpm_list_count(list), options_cmp);
for (i = list; i; i = alpm_list_next(i)) {
printf(%s, (char *)alpm_list_getdata(i));
}
--
1.7.3.1
Re: [pacman-dev] [PATCH] Sort short options before long options in --help
On Thu, Oct 14, 2010 at 3:44 PM, Dan McGee dpmc...@gmail.com wrote: Is the assert stuff you added to be safer? We don't want to use this. One, they are compiled into nothing if NDEBUG is defined, and two, it is a bit silly to abort on this condition. cmp(NULL, NULL) ==0, and then just decide whether to sort NULL first or last. It was not supposed to be safer, just to explicitly state that this case should not happen. If gettext returns NULL, our --help output is going to look awesome : (null)(null)(null).. It's not perfectly clear to me that an assert is worse. In the unlikely case that this could be triggered, at least an assert would fail gracefully telling us where it failed and possibly giving a core dump that would tell us more about what happened. Anyway we could debate over and over about assert usage. Maybe it's more interesting for an expensive check in a hot-path that you do not want to keep in a release build, but you want to make sure that the assert is indeed not triggered while developing / testing. I updated the patch with an explicit check (I actually already did this before choosing to use assert) : http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=parseargs
Re: [pacman-dev] [PATCH] Read 'force' entry from packages
On Tue, Oct 12, 2010 at 12:51 AM, Dan McGee d...@archlinux.org wrote:
We weren't reading this in from our packages, thus causing us not to write
it out to our local database. Adding this now will help ease the upgrade
path for epoch later and not require reinstallation of all force packages.
Signed-off-by: Dan McGee d...@archlinux.org
---
For maint, helps to address the problem Allan pointed out regarding upgrading
existing packages that used the force flag.
-Dan
lib/libalpm/be_package.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/libalpm/be_package.c b/lib/libalpm/be_package.c
index 38cf357..ff266ae 100644
--- a/lib/libalpm/be_package.c
+++ b/lib/libalpm/be_package.c
@@ -75,6 +75,8 @@ static int parse_descfile(struct archive *a, pmpkg_t
*newpkg)
STRDUP(newpkg-version, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
} else if(!strcmp(key, pkgdesc)) {
STRDUP(newpkg-desc, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
+ } else if(!strcmp(key, force)) {
+ newpkg-force = 1;
} else if(!strcmp(key, group)) {
newpkg-groups = alpm_list_add(newpkg-groups,
strdup(ptr));
} else if(!strcmp(key, url)) {
--
1.7.3.1
I did not see a problem with that patch, and still don't see any, but
I have some new insight after trying out git master.
I think we need a similar patch in master, we still need to support
old package with just force. We should do that just like sync db does
(force - epoch=1). This will ensure that epoch is always written in
local db for package with force.
diff --git a/lib/libalpm/be_package.c b/lib/libalpm/be_package.c
index ddcad59..254f830 100644
--- a/lib/libalpm/be_package.c
+++ b/lib/libalpm/be_package.c
@@ -184,6 +184,11 @@ static int parse_descfile(struct archive *a,
pmpkg_t *newpkg)
STRDUP(newpkg-version, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
} else if(strcmp(key, pkgdesc) == 0) {
STRDUP(newpkg-desc, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
+ } else if(strcmp(key, force) == 0) {
+ /* For backward compatibility, like in
sync_db_read */
+ if(!newpkg-epoch) {
+ newpkg-epoch = 1;
+ }
} else if(strcmp(key, epoch) == 0) {
newpkg-epoch = atoi(ptr);
} else if(strcmp(key, group) == 0) {
As for the maint patch, it seems weird that we will start to write
FORCE entries to local database now we decided to kill FORCE. Wouldn't
it be better to start writing EPOCH so that we don't start to clutter
the local db now with something which is dead ? :)
On my system I just have 17 packages to reinstall, 19MB download (but
0MB download actually, thats what a download cache is for). This is
done automatically on the first pacman -Su, and with above patch, the
transition should be made.
So I don't think we need to start writing anything to the local
database now, do we ?
If we still want to do that just to reduce a bit the (already small)
number of packages to reinstall, what about starting to write EPOCH in
maint ?
I believe we just need two small changes :
1) in maint : never write FORCE in local db but write EPOCH=1 instead
2) in master : we can drop reading FORCE from local db since it never
ever got written. (and EPOCH is already read)
But anyway this is really a minor point, and my last proposal would
actually need the 2-lines fix that got pushed to maint.
Re: [pacman-dev] [PATCH] Read 'force' entry from packages
On Thu, Oct 14, 2010 at 8:48 PM, Xavier Chantry
chantry.xav...@gmail.com wrote:
On Tue, Oct 12, 2010 at 12:51 AM, Dan McGee d...@archlinux.org wrote:
We weren't reading this in from our packages, thus causing us not to write
it out to our local database. Adding this now will help ease the upgrade
path for epoch later and not require reinstallation of all force packages.
Signed-off-by: Dan McGee d...@archlinux.org
---
For maint, helps to address the problem Allan pointed out regarding upgrading
existing packages that used the force flag.
-Dan
lib/libalpm/be_package.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/libalpm/be_package.c b/lib/libalpm/be_package.c
index 38cf357..ff266ae 100644
--- a/lib/libalpm/be_package.c
+++ b/lib/libalpm/be_package.c
@@ -75,6 +75,8 @@ static int parse_descfile(struct archive *a, pmpkg_t
*newpkg)
STRDUP(newpkg-version, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
} else if(!strcmp(key, pkgdesc)) {
STRDUP(newpkg-desc, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
+ } else if(!strcmp(key, force)) {
+ newpkg-force = 1;
} else if(!strcmp(key, group)) {
newpkg-groups =
alpm_list_add(newpkg-groups, strdup(ptr));
} else if(!strcmp(key, url)) {
--
1.7.3.1
I did not see a problem with that patch, and still don't see any, but
I have some new insight after trying out git master.
I think we need a similar patch in master, we still need to support
old package with just force. We should do that just like sync db does
(force - epoch=1). This will ensure that epoch is always written in
local db for package with force.
diff --git a/lib/libalpm/be_package.c b/lib/libalpm/be_package.c
index ddcad59..254f830 100644
--- a/lib/libalpm/be_package.c
+++ b/lib/libalpm/be_package.c
@@ -184,6 +184,11 @@ static int parse_descfile(struct archive *a,
pmpkg_t *newpkg)
STRDUP(newpkg-version, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
} else if(strcmp(key, pkgdesc) == 0) {
STRDUP(newpkg-desc, ptr,
RET_ERR(PM_ERR_MEMORY, -1));
+ } else if(strcmp(key, force) == 0) {
+ /* For backward compatibility, like in
sync_db_read */
+ if(!newpkg-epoch) {
+ newpkg-epoch = 1;
+ }
} else if(strcmp(key, epoch) == 0) {
newpkg-epoch = atoi(ptr);
} else if(strcmp(key, group) == 0) {
As for the maint patch, it seems weird that we will start to write
FORCE entries to local database now we decided to kill FORCE. Wouldn't
it be better to start writing EPOCH so that we don't start to clutter
the local db now with something which is dead ? :)
On my system I just have 17 packages to reinstall, 19MB download (but
0MB download actually, thats what a download cache is for). This is
done automatically on the first pacman -Su, and with above patch, the
transition should be made.
So I don't think we need to start writing anything to the local
database now, do we ?
If we still want to do that just to reduce a bit the (already small)
number of packages to reinstall, what about starting to write EPOCH in
maint ?
I believe we just need two small changes :
1) in maint : never write FORCE in local db but write EPOCH=1 instead
2) in master : we can drop reading FORCE from local db since it never
ever got written. (and EPOCH is already read)
But anyway this is really a minor point, and my last proposal would
actually need the 2-lines fix that got pushed to maint.
I just pushed this work, 3 small patches.
http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=epoch-maint
* be_files: write EPOCH instead of FORCE
http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=epoch-master
* be_package: read force entry and convert to epoch
* be_local: drop FORCE in db_read
Re: [pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.4.1-88-g46ffd34
On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee dpmc...@gmail.com wrote: Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.). -Dan Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
Re: [pacman-dev] [PATCH 4/4] CLI args: update --help and manpage
On Tue, Oct 12, 2010 at 4:04 AM, Dan McGee dpmc...@gmail.com wrote:
I'm not too thrilled abuot this patch for the fact that we lost alpha
ordering by shortopt for sync/upgrade/remove options. This is a step
backwards in my opinion.
I can deal with the dbpath/root/every single op uses these things
being at the bottom (and I think a blank line separating them would be
good too), but the list seems very mismanaged for the main ops now.
I pulled the other two patches in, but not this one.
usage: pacman {-S --sync} [options] [package(s)]
options:
--asdeps install packages as non-explicitly installed
--asexplicit install packages as explicitly installed
-c, --clean remove old packages from cache directory (-cc for all)
-d, --nodeps skip dependency checks
-f, --force force install, overwrite conflicting files
-g, --groups view all members of a package group
-i, --info view package information
-l, --list repoview a list of packages in a repo
-s, --search regex search remote repositories for matching strings
-u, --sysupgrade upgrade installed packages (-uu allows downgrade)
-w, --downloadonly download packages but do not install/upgrade anything
-y, --refreshdownload fresh package databases from the server
--needed don't reinstall up to date packages
--ignore pkg ignore a package upgrade (can be used more than once)
--ignoregroup grp
ignore a group upgrade (can be used more than once)
--print only print the targets instead of performing
the operation
--print-format string
specify how the targets should be printed
-q, --quiet show less information for query and search
--config path set an alternate configuration file
--logfile path set an alternate log file
--noconfirm do not ask for any confirmation
--noprogressbar do not show a progress bar when downloading files
--noscriptletdo not execute the install scriptlet if one exists
-v, --verbosebe verbose
--debug display debug messages
-r, --root pathset an alternate installation root
-b, --dbpath path set an alternate database location
--cachedir dir set an alternate package cache location
--arch archset an alternate architecture
I don't understand why it is fine to have -q -v -r -b mixed up like
that for the global section, but not have two other similar sections,
which makes it much nicer to check consistency of code, --help and
manpage. Isn't it nice to have that ?
Maybe you can only appreciate that patch if you try checking the
consistency before.
Otherwise we can just do pacman -Sh | sort :
--arch archset an alternate architecture
--asdeps install packages as non-explicitly installed
--asexplicit install packages as explicitly installed
-b, --dbpath path set an alternate database location
--cachedir dir set an alternate package cache location
-c, --clean remove old packages from cache directory (-cc for all)
--config path set an alternate configuration file
--debug display debug messages
-d, --nodeps skip dependency checks
-f, --force force install, overwrite conflicting files
-g, --groups view all members of a package group
ignore a group upgrade (can be used more than once)
--ignoregroup grp
--ignore pkg ignore a package upgrade (can be used more than once)
-i, --info view package information
-k, --dbonly only modify database entries, not package files
-l, --list repoview a list of packages in a repo
--logfile path set an alternate log file
--needed don't reinstall up to date packages
--noconfirm do not ask for any confirmation
--noprogressbar do not show a progress bar when downloading files
--noscriptletdo not execute the install scriptlet if one exists
--print-format string
--print only print the targets instead of performing
the operation
-q, --quiet show less information for query and search
-r, --root pathset an alternate installation root
specify how the targets should be printed
-s, --search regex search remote repositories for matching strings
-u, --sysupgrade upgrade installed packages (-uu allows downgrade)
-v, --verbosebe verbose
-w, --downloadonly download packages but do not install/upgrade anything
-y, --refreshdownload fresh package databases from the server
I suppose I could do that in code, just replace all printf by addlist,
sort the list at the end and print it.
That way the options will always appear in the same order, no matter
how they are written in the code.
[pacman-dev] [PATCH] alpm/remove.c : respect --dbonly during remove-upgrade
When a -Sk or -Uk operation induced a removal of an existing local
package, --dbonly was not in effect and the files were all removed.
Fixing this behavior was already marked as TODO in database012 pactest
TODO: I honestly think the above should NOT delete the original les, it
hould upgrade the DB entry without touching anything on the file stem.
E.g. this test should be the same as:
pacman -R --dbonly dummy pacman -U --dbonly dummy.pkg.tar.gz
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
doc/pacman.8.txt |2 --
lib/libalpm/remove.c |4
src/pacman/pacman.c |3 +--
test/pacman/tests/database012.py |8 +---
4 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt
index f389dfd..866c5a2 100644
--- a/doc/pacman.8.txt
+++ b/doc/pacman.8.txt
@@ -155,8 +155,6 @@ Transaction Options (apply to '-S', '-R' and '-U')
*-k, \--dbonly*::
Adds/Removes the database entry only, leaves all files in place.
- On an upgrade operation, the existing package and all files
- will be removed and the database entry for the new package will be
added.
*\--noprogressbar*::
Do not show a progress bar when downloading files. This can be useful
diff --git a/lib/libalpm/remove.c b/lib/libalpm/remove.c
index dfaba03..e0099fb 100644
--- a/lib/libalpm/remove.c
+++ b/lib/libalpm/remove.c
@@ -311,6 +311,9 @@ int _alpm_upgraderemove_package(pmpkg_t *oldpkg, pmpkg_t
*newpkg, pmtrans_t *tra
_alpm_log(PM_LOG_DEBUG, removing old package first (%s-%s)\n,
oldpkg-name, oldpkg-version);
+ if(trans-flags PM_TRANS_FLAG_DBONLY)
+ goto db;
+
/* copy the remove skiplist over */
skip_remove =
alpm_list_join(alpm_list_strdup(trans-skip_remove),alpm_list_strdup(handle-noupgrade));
@@ -345,6 +348,7 @@ int _alpm_upgraderemove_package(pmpkg_t *oldpkg, pmpkg_t
*newpkg, pmtrans_t *tra
alpm_list_free(newfiles);
FREELIST(skip_remove);
+db:
/* remove the package from the database */
_alpm_log(PM_LOG_DEBUG, updating database\n);
_alpm_log(PM_LOG_DEBUG, removing database entry '%s'\n, pkgname);
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index 933698e..4bf2613 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -90,7 +90,6 @@ static void usage(int op, const char * const myname)
printf(%s: %s {-R --remove} [%s] %s\n, str_usg,
myname, str_opt, str_pkg);
printf(%s:\n, str_opt);
printf(_( -c, --cascaderemove packages and
all packages that depend on them\n));
- printf(_( -k, --dbonly only remove database
entries, do not remove files\n));
printf(_( -n, --nosave remove configuration
files as well\n));
printf(_( -s, --recursive remove dependencies
also (that won't break packages)\n
(-ss includes
explicitly installed dependencies too)\n));
@@ -138,7 +137,6 @@ static void usage(int op, const char * const myname)
case PM_OP_SYNC:
case PM_OP_UPGRADE:
printf(_( -f, --force force install,
overwrite conflicting files\n));
- printf(_( -k, --dbonly add database
entries, do not install or keep existing files\n));
printf(_( --asdeps install
packages as non-explicitly installed\n));
printf(_( --asexplicit install
packages as explicitly installed\n));
printf(_( --ignore pkg ignore a
package upgrade (can be used more than once)\n));
@@ -147,6 +145,7 @@ static void usage(int op, const char * const myname)
/* pass through */
case PM_OP_REMOVE:
printf(_( -d, --nodeps skip
dependency checks\n));
+ printf(_( -k, --dbonly only modify
database entries, not package files\n));
printf(_( --noprogressbar do not show a
progress bar when downloading files\n));
printf(_( --noscriptletdo not execute
the install scriptlet if one exists\n));
printf(_( --print only print the
targets instead of performing the operation\n));
diff --git a/test/pacman/tests/database012.py b/test/pacman/tests/database012.py
index a1f8698..52813ec 100644
--- a/test/pacman/tests/database012.py
+++ b/test/pacman/tests/database012.py
@@ -21,11 +21,5 @@
self.addrule(PKG_EXIST=dummy)
self.addrule(PKG_VERSION=dummy|2.0-1)
for f in lp.files:
- self.addrule(!FILE_EXIST
[pacman-dev] [PATCH] add 3 pactests for -Sdd
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- test/pacman/tests/sync-sdd1.py | 15 +++ test/pacman/tests/sync-sdd2.py | 15 +++ test/pacman/tests/sync-sdd3.py | 15 +++ 3 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 test/pacman/tests/sync-sdd1.py create mode 100644 test/pacman/tests/sync-sdd2.py create mode 100644 test/pacman/tests/sync-sdd3.py diff --git a/test/pacman/tests/sync-sdd1.py b/test/pacman/tests/sync-sdd1.py new file mode 100644 index 000..184a66d --- /dev/null +++ b/test/pacman/tests/sync-sdd1.py @@ -0,0 +1,15 @@ +self.description = -Sdd: -Sdd works + +p1 = pmpkg(pkg1, 1.0-2) +p1.depends = [provision=1.0-2] +self.addpkg2db(sync, p1) + +p2 = pmpkg(pkg2, 1.0-2) +p2.provides = [provision=1.0-1] +self.addpkg2db(sync, p2) + +self.args = -Sdd %s % p1.name + +self.addrule(PACMAN_RETCODE=0) +self.addrule(PKG_EXIST=pkg1) +self.addrule(PKG_EXIST=pkg2) diff --git a/test/pacman/tests/sync-sdd2.py b/test/pacman/tests/sync-sdd2.py new file mode 100644 index 000..5f1f847 --- /dev/null +++ b/test/pacman/tests/sync-sdd2.py @@ -0,0 +1,15 @@ +self.description = -Sdd: -S fails + +p1 = pmpkg(pkg1, 1.0-2) +p1.depends = [provision=1.0-2] +self.addpkg2db(sync, p1) + +p2 = pmpkg(pkg2, 1.0-2) +p2.provides = [provision=1.0-1] +self.addpkg2db(sync, p2) + +self.args = -S %s % p1.name + +self.addrule(PACMAN_RETCODE=1) +self.addrule(!PKG_EXIST=pkg1) +self.addrule(!PKG_EXIST=pkg2) diff --git a/test/pacman/tests/sync-sdd3.py b/test/pacman/tests/sync-sdd3.py new file mode 100644 index 000..68733af --- /dev/null +++ b/test/pacman/tests/sync-sdd3.py @@ -0,0 +1,15 @@ +self.description = -Sdd: -Sd works but no deps + +p1 = pmpkg(pkg1, 1.0-2) +p1.depends = [provision=1.0-2] +self.addpkg2db(sync, p1) + +p2 = pmpkg(pkg2, 1.0-2) +p2.provides = [provision=1.0-1] +self.addpkg2db(sync, p2) + +self.args = -Sd %s % p1.name + +self.addrule(PACMAN_RETCODE=0) +self.addrule(PKG_EXIST=pkg1) +self.addrule(!PKG_EXIST=pkg2) -- 1.7.3.1
[pacman-dev] [PATCH 3/4] CLI args: stricter/better parsing
From: Jakob Gruber jakob.gru...@gmail.com
In the following, the letters SRUDQ refer to the corresponding pacman
operations.
Most of the work in this commit is about removing as many options as
possible from the global section and moving them to where they actually
belong.
Additionally, --ignore{,group} are added to U and --dbonly is added
to S.
--dbonly added to S
--asdeps moved to S/U/D
--asexplicit moved to S/U/D
--print-format moved to S/U/R
--noprogressbar moved to S/U/R
--noscriptlet moved to S/U/R
--ignorepkg added to U
--ignoregrp added to U
-d moved to S/U/R (--nodeps) and Q (--deps)
-p moved to S/U/R (--print) and Q (--file)
-f moved to S/U
---
doc/pacman.8.txt| 26 ++---
src/pacman/pacman.c | 77 +-
2 files changed, 60 insertions(+), 43 deletions(-)
diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt
index de1f51f..4a936c8 100644
--- a/doc/pacman.8.txt
+++ b/doc/pacman.8.txt
@@ -158,6 +158,16 @@ Options
*\--config* 'file'::
Specify an alternate configuration file.
+*\--ignore* 'package'::
+ Directs pacman to ignore upgrades of package even if there is one
+ available. Multiple packages can be specified by separating them
+ with a comma.
+
+*\--ignoregroup* 'group'::
+ Directs pacman to ignore upgrades of all packages in 'group' even if
+ there is one available. Multiple groups can be specified by
+ separating them with a comma.
+
*\--logfile* 'file'::
Specify an alternate log file. This is an absolute path, regardless of
the installation root setting.
@@ -321,6 +331,10 @@ linkman:pacman.conf[5].
or '-i' flags will also display those packages in all repositories that
depend on this package.
+*-k, \--dbonly*::
+ Adds the database entries for the specified packages but does not
install any
+ of the files.
+
*-l, \--list*::
List all packages in the specified repositories. Multiple repositories
can be specified on the command line.
@@ -365,21 +379,11 @@ linkman:pacman.conf[5].
*\--needed*::
Don't reinstall the targets that are already up-to-date.
-*\--ignore* 'package'::
- Directs pacman to ignore upgrades of package even if there is one
- available. Multiple packages can be specified by separating them
- with a comma.
-
-*\--ignoregroup* 'group'::
- Directs pacman to ignore upgrades of all packages in 'group' even if
- there is one available. Multiple groups can be specified by
- separating them with a comma.
-
Upgrade Options[[UO]]
*-k, \--dbonly*::
- Adds the database entries for the specified packages but do not install
any
+ Adds the database entries for the specified packages but does not
install any
of the files. On an upgrade operation, the existing package and all
files
will be removed and the database entry for the new package will be
added.
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index f725071..15abecc 100644
--- a/src/pacman/pacman.c
+++ b/src/pacman/pacman.c
@@ -352,6 +352,21 @@ static void setlibpaths(void)
#define check_optarg() if(!optarg) { return(1); }
+typedef void (*fn_add) (const char *s);
+
+static int parsearg_util_addlist(fn_add fn)
+{
+ alpm_list_t *list = NULL, *item = NULL; /* lists for splitting strings
*/
+
+ check_optarg();
+ list = strsplit(optarg, ',');
+ for(item = list; item; item = alpm_list_next(item)) {
+ fn((char *)alpm_list_getdata(item));
+ }
+ FREELIST(list);
+ return(0);
+}
+
/** Helper function for parsing operation from command-line arguments.
* @param opt Keycode returned by getopt_long
* @param dryrun If nonzero, application state is NOT changed
@@ -398,8 +413,6 @@ static int parsearg_op(int opt, int dryrun)
static int parsearg_global(int opt)
{
switch(opt) {
- case OP_ASDEPS: config-flags |= PM_TRANS_FLAG_ALLDEPS; break;
- case OP_ASEXPLICIT: config-flags |= PM_TRANS_FLAG_ALLEXPLICIT;
break;
case OP_ARCH: check_optarg(); setarch(optarg); break;
case OP_ASK:
check_optarg();
@@ -449,22 +462,10 @@ static int parsearg_global(int opt)
config-logfile = strndup(optarg, PATH_MAX);
break;
case OP_NOCONFIRM: config-noconfirm = 1; break;
- case OP_NOPROGRESSBAR: config-noprogressbar = 1; break;
- case OP_NOSCRIPTLET: config-flags |=
PM_TRANS_FLAG_NOSCRIPTLET; break;
- case OP_PRINTFORMAT:
- check_optarg();
- config-print_format = strdup(optarg);
- break;
case 'b':
check_optarg();
config-dbpath = strdup(optarg);
break;
- case 'd':
-
[pacman-dev] [PATCH 4/4] CLI args: update --help and manpage
The three parts (help, manpage and code) are now organized in the same way and much easier to compare : - specific options - install/upgrade options for -S and -U - transaction options for -S -R and -U - global options After this re-organization, it was easy to update and sync the three components together. Duplication is also avoided. Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- doc/pacman.8.txt| 110 -- src/pacman/pacman.c | 164 +-- 2 files changed, 133 insertions(+), 141 deletions(-) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 4a936c8..f389dfd 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -104,35 +104,12 @@ to determine which packages need upgrading. This behavior operates as follows: Options --- -*\--asdeps*:: - Install packages non-explicitly; in other words, fake their install reason - to be installed as a dependency. This is useful for makepkg and other - build from source tools that need to install dependencies before building - the package. - -*\--asexplicit*:: - Install packages explicitly; in other words, fake their install reason to - be explicitly installed. This is useful if you want to mark a dependency - as explicitly installed so it will not be removed by the '\--recursive' - remove operation. - *-b, \--dbpath* 'path':: Specify an alternative database location (a typical default is ``/var/lib/pacman''). This should not be used unless you know what you are doing. *NOTE*: if specified, this is an absolute path and the root path is not automatically prepended. -*-d, \--nodeps*:: - Skips all dependency checks. Normally, pacman will always check a - package's dependency fields to ensure that all dependencies are - installed and there are no package conflicts in the system. - -*-f, \--force*:: - Bypass file conflict checks and overwrite conflicting files. If the - package that is about to be installed contains files that are already - installed, this option will cause all those files to be overwritten. - This option should be used with care, ideally not at all. - *-r, \--root* 'path':: Specify an alternative installation root (default is ``/''). This should not be used as a way to install software into ``/usr/local'' instead of @@ -145,9 +122,8 @@ Options *-v, \--verbose*:: Output paths such as as the Root, Conf File, DB Path, Cache Dirs, etc. -*\--debug*:: - Display debug messages. When reporting bugs, this option is recommended - to be used. +*\--arch* 'arch':: + Specify an alternate architecture. *\--cachedir* 'dir':: Specify an alternative package cache location (a typical default is @@ -158,15 +134,9 @@ Options *\--config* 'file':: Specify an alternate configuration file. -*\--ignore* 'package':: - Directs pacman to ignore upgrades of package even if there is one - available. Multiple packages can be specified by separating them - with a comma. - -*\--ignoregroup* 'group':: - Directs pacman to ignore upgrades of all packages in 'group' even if - there is one available. Multiple groups can be specified by - separating them with a comma. +*\--debug*:: + Display debug messages. When reporting bugs, this option is recommended + to be used. *\--logfile* 'file':: Specify an alternate log file. This is an absolute path, regardless of @@ -176,6 +146,18 @@ Options Bypass any and all ``Are you sure?'' messages. It's not a good idea to do this unless you want to run pacman from a script. +Transaction Options (apply to '-S', '-R' and '-U') +-- +*-d, \--nodeps*:: + Skips all dependency checks. Normally, pacman will always check a + package's dependency fields to ensure that all dependencies are + installed and there are no package conflicts in the system. + +*-k, \--dbonly*:: + Adds/Removes the database entry only, leaves all files in place. + On an upgrade operation, the existing package and all files + will be removed and the database entry for the new package will be added. + *\--noprogressbar*:: Do not show a progress bar when downloading files. This can be useful for scripts that call pacman and capture the output. @@ -184,19 +166,46 @@ Options If an install scriptlet exists, do not execute it. Do not use this unless you know what you are doing. -*\--arch* 'arch':: - Specify an alternate architecture. - *-p, \--print*:: Only print the targets instead of performing the actual operation (sync, - remove or upgrade). Use '\--print-format' to specify how targets are - displayed. The default format string is %l, which displays url with '-S
[pacman-dev] [PATCH 1/2] pactest: use simpler method to create tar
just like in 24fc623e1a8bf905cf0367f9bd40bc5bd6034378 , apply to pmdb
gensync as well.
---
test/pacman/pmdb.py |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/test/pacman/pmdb.py b/test/pacman/pmdb.py
index 41bd738..11083db 100755
--- a/test/pacman/pmdb.py
+++ b/test/pacman/pmdb.py
@@ -346,11 +346,8 @@ def gensync(self, path):
mkdir(path)
archive = os.path.join(path, %s.db % (self.treename))
tar = tarfile.open(archive, w:gz)
-for root, dirs, files in os.walk('.'):
-for d in dirs:
-tar.add(os.path.join(root, d), recursive=False)
-for f in files:
-tar.add(os.path.join(root, f))
+for i in os.listdir(.):
+tar.add(i)
tar.close()
os.chdir(curdir)
--
1.7.3.1
[pacman-dev] [PATCH 2/2] pactest: fix gensync
gensync generated a sync.db file with PKGINFO
syntax, this is not quite what pacman expects.
Also the file was only added to the Server path :
root/var/pub/sync/sync.db
but it was not available in the normal sync db path :
root/var/lib/pacman/sync/sync.db
change gensync() to generate var/lib/pacman/sync/sync.db and then copy
it to var/pub/sync/sync.db (this is used by sync200 -Sy test)
---
test/pacman/pmdb.py | 30 +-
test/pacman/pmtest.py | 12 +++-
test/pacman/util.py |1 +
3 files changed, 21 insertions(+), 22 deletions(-)
Allan will be happy.. hopefully :)
diff --git a/test/pacman/pmdb.py b/test/pacman/pmdb.py
index 11083db..efd0cc2 100755
--- a/test/pacman/pmdb.py
+++ b/test/pacman/pmdb.py
@@ -81,11 +81,15 @@ class pmdb:
Database object
-def __init__(self, treename, dbdir):
+def __init__(self, treename, root):
self.treename = treename
-self.dbdir = dbdir
self.pkgs = []
self.option = {}
+if self.treename == local:
+self.dbdir = os.path.join(root, PM_DBPATH, treename)
+else:
+self.dbdir = os.path.join(root, PM_SYNCDBPATH, treename)
+self.dbfile = os.path.join(root, PM_SYNCDBPATH, treename + .db)
def __str__(self):
return %s % self.treename
@@ -101,7 +105,7 @@ def db_read(self, name):
-path = os.path.join(self.dbdir, self.treename)
+path = self.dbdir
if not os.path.isdir(path):
return None
@@ -227,10 +231,7 @@ def db_write(self, pkg):
-if self.treename == local:
-path = os.path.join(self.dbdir, self.treename, pkg.fullname())
-else:
-path = os.path.join(self.dbdir, sync, self.treename,
pkg.fullname())
+path = os.path.join(self.dbdir, pkg.fullname())
mkdir(path)
# desc
@@ -331,27 +332,22 @@ def db_write(self, pkg):
pkg.checksum[install] = getmd5sum(filename)
pkg.mtime[install] = getmtime(filename)
-def gensync(self, path):
+def gensync(self):
+if not self.dbfile:
+return
curdir = os.getcwd()
-tmpdir = tempfile.mkdtemp()
-os.chdir(tmpdir)
-
-for pkg in self.pkgs:
-mkdescfile(pkg.fullname(), pkg)
+os.chdir(self.dbdir)
# Generate database archive
-mkdir(path)
-archive = os.path.join(path, %s.db % (self.treename))
-tar = tarfile.open(archive, w:gz)
+tar = tarfile.open(self.dbfile, w:gz)
for i in os.listdir(.):
tar.add(i)
tar.close()
os.chdir(curdir)
-shutil.rmtree(tmpdir)
def ispkgmodified(self, pkg):
diff --git a/test/pacman/pmtest.py b/test/pacman/pmtest.py
index 5c8881c..c476929 100755
--- a/test/pacman/pmtest.py
+++ b/test/pacman/pmtest.py
@@ -47,7 +47,7 @@ def addpkg2db(self, treename, pkg):
if not treename in self.db:
-self.db[treename] = pmdb.pmdb(treename, os.path.join(self.root,
PM_DBPATH))
+self.db[treename] = pmdb.pmdb(treename, self.root)
self.db[treename].pkgs.append(pkg)
def addpkg(self, pkg):
@@ -73,7 +73,7 @@ def load(self):
self.args =
self.retcode = 0
self.db = {
-local: pmdb.pmdb(local, os.path.join(self.root, PM_DBPATH))
+local: pmdb.pmdb(local, self.root)
}
self.localpkgs = []
self.filesystem = []
@@ -152,9 +152,11 @@ def generate(self):
vprint(Creating sync database archives)
for key, value in self.db.iteritems():
if key == local: continue
-archive = value.treename + .db
-vprint(\t + os.path.join(SYNCREPO, archive))
-value.gensync(os.path.join(syncdir, value.treename))
+vprint(\t + value.treename)
+value.gensync()
+serverpath = os.path.join(syncdir, value.treename)
+mkdir(serverpath)
+shutil.copy(value.dbfile, serverpath)
# Filesystem
vprint(Populating file system)
diff --git a/test/pacman/util.py b/test/pacman/util.py
index 657230e..802f22e 100755
--- a/test/pacman/util.py
+++ b/test/pacman/util.py
@@ -25,6 +25,7 @@
# ALPM
PM_ROOT = /
PM_DBPATH = var/lib/pacman
+PM_SYNCDBPATH = var/lib/pacman/sync
PM_LOCK = var/lib/pacman/db.lck
PM_CACHEDIR = var/cache/pacman/pkg
PM_EXT_PKG = .pkg.tar.gz
--
1.7.3.1
Re: [pacman-dev] [PATCH 0/5] RFC: epoch implementation
On Sat, Oct 9, 2010 at 3:47 AM, Allan McRae al...@archlinux.org wrote: I just took these for a spin al...@mugen /home/arch/code/pacman (epoch) sudo ./src/pacman/pacman -Syu snip Targets (24): blas-3.2.2-2 crafty-23.3-1 db-4.8.26-2 foomatic-db-4.0.5_20100816-1 foomatic-filters-4.0.5_20100816-1 foomatic-db-engine-4.0.5_20100816-1 ghostscript-9.00-1 gsfonts-1.0.7pre44-2 imagemagick-6.6.4.3-1 libffi-3.0.9-1 libimobiledevice-1.0.3-1 libraw1394-2.0.5-1 libshout-2.2.2-3 libvdpau-0.4-1 sqlite3-3.7.3-1 qt-4.7.0-3 rasqal-0.9.20-1 redland-1.0.11-1 soundconverter-1.5.3-4 tdb-1.2.1-2 ttf-liberation-1.06.0.20100721-1 vim-runtime-7.3.3-2 vim-7.3.3-2 vte-0.26.0-4 Total Download Size: 37.54 MB Total Installed Size: 264.40 MB ... So these are all the packages on your system with force flag ? Maybe now would be a good time to review which of those really need force flag, drop it if it has been unnecessary for a while. Then if upstream mess up version again or for next need of downgrade, start using epoch. Btw this problem happens just once , right ? After this first reinstall of force package, epoch gets written to local database and then it's fine ?
Re: [pacman-dev] Sodeps support
On Fri, Oct 8, 2010 at 12:50 PM, Florian Pritz bluew...@server-speed.net wrote: On Fri, 1 Oct 2010 17:30:03 +0200, Florian Pritz bluew...@xssn.at wrote: These patches add a -dd option which ignores the version of dependencies only and sodependencies. They are also available online at http://git.server-speed.net/users/flo/pacman/ Someone please signoff the pacman patches (1 and 4) so Allan can merge. make check failed with deptest001 : pacman -T 'foo1' segfaulted because we don't have a transaction in this case. Added a quick helper that uses alpm_get_trans_flags and check for -1. Also slightly changed the second patch to do just once : if (nodeps) else http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=sodeps
Re: [pacman-dev] [PATCH] makepkg: canonicalize paths from environmental variables
On Wed, Sep 29, 2010 at 3:52 PM, Allan McRae al...@archlinux.org wrote: Just to clarify (thanks to Xavier), it worked on BSD but not in OSX which does not have either readlink -f or realpath... just found a link that might help : http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac To sum up the solutions : 1) use python os.path.realpath 2) use C realpath (3) 3) use fink /sw/sbin/readlink -f 4) implement in bash Someone already proposed 4) a while ago : http://mailman.archlinux.org/pipermail/pacman-dev/2009-February/008147.html I did not compare this bash implementation with the one found on stackoverflow. The best might still be to see if there is any way to avoid using realpath, like I did for repo-add back then. But maybe there is really no way out for makepkg, I don't know.
Re: [pacman-dev] python-2.7 and pacman test-suite
On Tue, Sep 28, 2010 at 4:23 PM, Dan McGee dpmc...@gmail.com wrote: Xavier, any insight or memory why you did it this way? commit c465d9e848b19b495259c7021a583c29fba92b44 Author: Chantry Xavier shinin...@gmail.com Date: Thu Apr 17 09:02:11 2008 +0200 pactest : Use tarfile module. There was no reason to write it that way, it looks quite stupid, but it's just the first method I found and it worked. I found an old mail when I was looking how to replace the 'tar cf *' call with python tarfile. os.listdir is actually closer to * than os.walk. I looked a bit at using tarfile, my main problem is the *, I am not sure this is available in python. And I don't know how to emulate it either (all files/dirs in the current directory that dont start with . ?)
Re: [pacman-dev] [PATCH 1/5] Tests: Adjust sync023 to correctly test FS#20221
On Mon, Sep 27, 2010 at 8:38 PM, Jakob Gruber jakob.gru...@gmail.com wrote:
I couldn't see how the original test made any sense, so I adjusted it to
test FS#20221 (as specified in commit
e702f56ea671c6cd1154a0ddb41fa63e97587c85).
The old PKG_EXIST rules do nothing because pkg{1,2,3} are created in both
the local repo and the sync repo.
Likewise, the old PKG_VERSION rule has no effect because pkg1 is version
1.1-1 in all (local, sync, testing) repos.
So the only thing it actually tests is that '-S --needed grp' runs without
errors, and my updated test also checks for that.
Or did I miss something? If you'd still like to have it as a separate test,
let me know.
Maybe what you missed is that the default version is 1.0-1 ?
The existing sync023 pactest looks good to me.
Re: [pacman-dev] [PATCH 2/2] use execv to avoid using sh just to run ldconfig
On Wed, Aug 18, 2010 at 2:07 PM, Jonathan Conder j...@skurvy.no-ip.org wrote: Signed-off-by: Jonathan Conder j...@skurvy.no-ip.org --- lib/libalpm/trans.c | 5 - lib/libalpm/util.c | 11 ++- lib/libalpm/util.h | 2 +- 3 files changed, 11 insertions(+), 7 deletions(-) I just improved the debug output for this patch, which I've been meaning to do since I first submitted it. I already ack-ed both a while ago and had merged them in my tree, but for some reasons they stayed there. So new ack for the 2 lines change, and merged to my working branch again ;) http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working
Re: [pacman-dev] replaces vs conflicts
On Fri, Aug 13, 2010 at 1:46 PM, Allan McRae al...@archlinux.org wrote: I got a conflict too. pacman 3.4.0-2 Great, I am not going mad. But not great, something strange is happening... Can you show debug output ? And libelf is not in any of your sync repo, ie pacman -Si libelf does not return anything ?
Re: [pacman-dev] replaces vs conflicts
On Fri, Aug 13, 2010 at 8:54 PM, Florian Pritz bluew...@server-speed.net wrote: On 13.08.2010 20:42, Xavier Chantry wrote: On Fri, Aug 13, 2010 at 1:46 PM, Allan McRae al...@archlinux.org wrote: I got a conflict too. pacman 3.4.0-2 Great, I am not going mad. But not great, something strange is happening... Can you show debug output ? And libelf is not in any of your sync repo, ie pacman -Si libelf does not return anything ? According to my (some hours old) database it has been in core. Well the code does this (sync.c) : /* Search for literal then replacers in each sync database. * If found, don't check other databases */ So if the literal (libelf) still exists in the db, the replacer (elfutils) isn't even considered. But it's then pulled as a dep for gcc, thus the conflict message.
Re: [pacman-dev] Explicit (opt)deps for makepkg.
On Mon, Jul 19, 2010 at 12:15 PM, k...@krzd.net wrote: Sure that in this case you don't need a patch, but where is the problem to file a simple bug report. Just two lines of text and everything is allright. Just my two cents Please... the developers can talk for themselves... and these people actually know that Xyne filed a bug there after his mail : http://bugs.archlinux.org/task/20217 But that's not even the problem. However if you have something productive to contribute to the original deps problem, go ahead.
Re: [pacman-dev] [PATCH 2/6] Remove use of gpgme
On Wed, Jul 7, 2010 at 7:43 PM, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: gpgme is very good when the keyring is the default, or if the requirements are simple. But for a specialized keyring, like pacman's, it is not flexible enough. This patch removes the checking of configure.ac. This patch in itself doesn't make much sense. Instead you would want to have one self-contained patch that does a simple conversion from gpgme to gpg cli. This move could be split in several steps, but then only in the last step which completely removes the gpgme dependency, you can also remove the checking of configure.ac Anyway, this is not a light step we are talking about here, it's a big implementation change which causes a complete rewrite. Rewrite are not bad, sometimes they are very good and much needed. But I am still waiting for a better and more verbose justification. Dan, you mentioned some times ago you also spotted some limitations in gpgme, does it match Denis' description ? Is there really no way around ? And as always, I don't think that re-implementing the wheel without even knowing the good and bad sides of the existing implementations is a good idea. It would be interesting to know what the other package managers use.
[pacman-dev] [PATCH 3/3] manpage: add real world examples
From: Nico Schottelius n...@kr.ethz.ch Signed-off-by: Nico Schottelius n...@kr.ethz.ch Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- doc/pacman.8.txt | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 3d14a42..de1f51f 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -415,6 +415,25 @@ original=X, current=Y, new=Z:: necessary changes into the original file. +Examples + + +pacman -Ss ne.hack:: + Search for regexp ne.hack in package database. + +pacman -S gpm:: + Download and install gpm including dependencies. + +pacman -U /home/user/ceofhack-0.6-1-x86_64.pkg.tar.gz:: + Install ceofhack-0.6-1 package from a local file. + +pacman -Syu:: + Update package list and upgrade all packages afterwards. + +pacman -Syu gpm:: + Update package list, upgrade all packages, and then install gpm if it + wasn't already installed. + Configuration - See linkman:pacman.conf[5] for more details on configuring pacman using the -- 1.7.1.1
Re: [pacman-dev] [PATCH] makepkg: fix sudo/su calling of pacman
On Thu, Jul 1, 2010 at 3:08 AM, Loui Chang louipc@gmail.com wrote: On Wed 30 Jun 2010 20:08 -0430, Andres P wrote: Also, how do I unsubscribe from this shitty list? ;) Heyy. Don't be so rude now. The list isn't that bad. http://mailman.archlinux.org/mailman/listinfo/pacman-dev I always wondered what kind of people cannot find by themselves how to unsubscribe from a ML and feel obliged to spam and insult all of its users to ask. It's definitely not the first time I see this behavior, I've already seen it on some arch ML before.
Re: [pacman-dev] Transifex
On Thu, Jul 1, 2010 at 11:53 AM, 甘露(Gan Lu) rhythm@gmail.com wrote: I see there is a page [1] in Transifex for pacman/libpalm, could any dev gives me a permission to submit my translation from there? I am used to maintain Chinese simplified translation, thanks. [1] http://www.transifex.net/projects/p/archlinux-pacman/ Just request a new translation team there. If I see a request from a known translator, I will accept it (or Dan).
[pacman-dev] [PATCH 3/3] manpage: add real world examples
From: Nico Schottelius n...@kr.ethz.ch Signed-off-by: Nico Schottelius n...@kr.ethz.ch Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- doc/pacman.8.txt | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 3d14a42..e66e25c 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -415,6 +415,28 @@ original=X, current=Y, new=Z:: necessary changes into the original file. +Examples + + +pacman -Ss ne.hack:: + Search for regexp ne.hack in package database. + +pacman -S gpm:: + Download and install gpm including dependencies. + +pacman -U /home/nico/ceofhack-0.6-1-x86_64.pkg.tar.gz:: + Install ceofhack from a package file (as genererated by PKGBUILD from AUR). + +pacman -Syu:: + Update package list and upgrade all packages afterwards. + +pacman -Syu gpm:: + Update package list, upgrade all packages, and then install or upgrade gpm. + +pacman -Scc:: + Remove *all* packages from cache (-Sc removes only uninstalled ones). + + Configuration - See linkman:pacman.conf[5] for more details on configuring pacman using the -- 1.7.1.1
Re: [pacman-dev] [PATCH 1/2] redirect scriptlet stderr synchronously through alpm
On Thu, Jun 24, 2010 at 9:57 PM, Andres P aep...@gmail.com wrote: On Mon, May 24, 2010 at 2:19 AM, Jonathan Conder j...@skurvy.no-ip.org wrote: Fixes FS#18770, and hopefully an occasional deadlock in my frontend as well. For simplicity it redirects all scriptlet output through SCRIPTLET_INFO, and all callbacks in the child process have been replaced for thread-safety. Also adds a shell to the fake root set up for pactests, which was not needed previously due to a bug (debian #582847) in fakechroot. Signed-off-by: Jonathan Conder j...@skurvy.no-ip.org What's the status on this patch? I liked them so I pushed them to my branch : http://code.toofishes.net/cgit/xavier/pacman.git/log/?h=working I suppose Dan will look at them when he has time, and that they are not maint-worthy, so they will wait until next major release. i.e. no big hurry.
Re: [pacman-dev] [PATCH] manpage update: add real world examples with full path
On Mon, Jun 14, 2010 at 3:41 PM, Allan McRae al...@archlinux.org wrote: == ERROR: PKGBUILD does not exist. What is a PKGBUILD? There are heaps of links in man makepkg to a PKGBUILD man page so... al...@mugen ~ man PKGBUILD Now, that does not say where to find the prototypes, but I think it is the PKGBUILD man page that should be adjusted. It also should be adjusted to remove reference to Arch. But it does provide examples. Also, the directory /usr/share/pacman is configurable, so should not be hard coded. I just see now that my git tree is dirty with a previous version of that patch. So NAK on the makepkg part but the pacman one is fine ? I think Nico put enough effort with many resubmits already, and the idea is not bad, so I can just pick the pacman part of the last patch and push that to my tree, if that's ok.
Re: [pacman-dev] Warnings with -D_FORTIFY_SOURCE=2
On Mon, Jun 14, 2010 at 11:35 AM, Allan McRae al...@archlinux.org wrote: Hi, Trying to build pacman with the gcc flag -D_FORTIFY_SOURCE=2 gives a bunch of warnings like: add.c:586:8: warning: ignoring return value of ‘chdir’, declared with attribute warn_unused_result be_files.c:660:9: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result util.c:146:9: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result pacman.c:712:8: warning: ignoring return value of ‘getcwd’, declared with attribute warn_unused_result util.c:796:12: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result There are 21 warnings in total. Would there be in interest in adding the return value check (some of which would be basically useless...) and adding -D_FORTIFY_SOURCE=2 to the CFLAGS when used with --enable-debug? If it's easy to check (because the function already does some error handling, or it is easy to add), then go for it.
Re: [pacman-dev] [PATCH] manpage example updates
On Mon, Jun 14, 2010 at 1:23 PM, Nico Schottelius nico-pacman-...@schottelius.org wrote: From: Nico Schottelius n...@kr.ethz.ch Signed-off-by: Nico Schottelius n...@kr.ethz.ch --- doc/makepkg.8.txt | 16 doc/pacman.8.txt | 19 +++ 2 files changed, 35 insertions(+), 0 deletions(-) diff --git a/doc/makepkg.8.txt b/doc/makepkg.8.txt index a2fdb3f..da8d750 100644 --- a/doc/makepkg.8.txt +++ b/doc/makepkg.8.txt @@ -187,6 +187,22 @@ Environment Variables corresponding value defined in linkman:makepkg.conf[5]. +Examples + +To create a new package from scratch and let makepkg handle integrity checks: + + $ mkdir mypkg + $ cd mypkg + # create PKGBUILD + $ makepkg -g PKGBUILD + $ makepkg + +Files +- +PKGBUILD:: + Package build description file in the *current* directory. + + Configuration - See linkman:makepkg.conf[5] for more details on configuring makepkg using the diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 3d14a42..febb802 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -415,6 +415,25 @@ original=X, current=Y, new=Z:: necessary changes into the original file. +Examples + + +pacman -Ss 'regexp':: + Search for regexp in package database. + +pacman -S 'packages':: + Download and install packages including dependencies. + +pacman -U 'paths':: + Install package found in the specified file(s). + +pacman -Syu:: + Update package list and upgrade all packages afterwards. + +pacman -Scc:: + Remove *all* packages from cache (-Sc removes only uninstalled ones). + + That looks good to me. I am just wondering if instead of 'regexp' 'packages' 'paths' , we want to put specific examples there. Just to increase the differences between general descriptions and examples section. What do you think ?
Re: [pacman-dev] [PATCH] manpage update: add real world examples
On Mon, Jun 14, 2010 at 1:55 PM, Nico Schottelius nico-pacman-...@schottelius.org wrote: From: Nico Schottelius n...@kr.ethz.ch Signed-off-by: Nico Schottelius n...@kr.ethz.ch --- doc/makepkg.8.txt | 16 doc/pacman.8.txt | 19 +++ 2 files changed, 35 insertions(+), 0 deletions(-) diff --git a/doc/makepkg.8.txt b/doc/makepkg.8.txt index a2fdb3f..da8d750 100644 --- a/doc/makepkg.8.txt +++ b/doc/makepkg.8.txt @@ -187,6 +187,22 @@ Environment Variables corresponding value defined in linkman:makepkg.conf[5]. +Examples + +To create a new package from scratch and let makepkg handle integrity checks: + + $ mkdir mypkg + $ cd mypkg + # create PKGBUILD + $ makepkg -g PKGBUILD + $ makepkg + +Files +- +PKGBUILD:: + Package build description file in the *current* directory. + + Configuration - See linkman:makepkg.conf[5] for more details on configuring makepkg using the diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 3d14a42..69bed21 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -415,6 +415,25 @@ original=X, current=Y, new=Z:: necessary changes into the original file. +Examples + + +pacman -Ss ne.hack:: + Search for regexp ne.hack in package database. + +pacman -S gpm:: + Download and install gpm including dependencies. + +pacman -U ./ceofhack-0.6.tar.xz:: + Install ceofhack found in the local file ceofhack-0.6.tar.xz. + +pacman -Syu:: + Update package list and upgrade all packages afterwards. + +pacman -Scc:: + Remove *all* packages from cache (-Sc removes only uninstalled ones). + + Configuration - See linkman:pacman.conf[5] for more details on configuring pacman using the -- 1.7.1 I like this, just one comment left : I would rather use a standard filename produced by makepkg. This is not enforced by pacman, but I would rather put one anyway in the man page, e.g. zlib-1.2.5-1-x86_64.pkg.tar.xz (-rel version , arch , .pkg) And hopefully people know that ./ is not necessary and just indicate a path.
Re: [pacman-dev] Examples in the manpages
On Sun, Jun 13, 2010 at 2:53 AM, Nico Schottelius nico-pacman-...@schottelius.org wrote: Dear pacman-devs, after a funny replace pacman-with-pacman-git evening, I digged around a bit into makepkg and pacman and noticed there are no examples in the manpages. Is that intented or would you like to/accept patches which add the EXAMPLES section? I remember a discussion about this on irc a while ago. I completely agree that EXAMPLES section is very nice, it's always the first thing I look up in a man page of a new program, and I am disappointed when I don't find any, and delighted when I find one :) However, I was also wondering some times ago what the purpose of our wiki page was. It seemed like a duplicate of our man pages, and thus two places we needed to keep in sync and update. Then I realized the wiki page was actually the EXAMPLES section we don't have, it doesn't present options like in our man pages, it presents them by examples. http://wiki.archlinux.org/index.php/Pacman So I am happy with how things are now, adding something has the risk of causing more duplication and more work.
Re: [pacman-dev] Examples in the manpages
On Sun, Jun 13, 2010 at 2:34 PM, Nico Schottelius nico-pacman-...@schottelius.org wrote: And another one for makepkg, which would saved my a lot of time searching around the net: http://git.schottelius.org/?p=foreign/pacman;a=commitdiff;h=9abd1a4c00cd0e0b29948cdfc51364ba249fdace As I said, I am happy with just having examples on the wiki page. If you insist on having an examples section in the man pages, please re-send your patch inline, like with git send-email. That would allow us to give inline comments.
Re: [pacman-dev] [PATCH 1/2] add two entries to pacman manpage examples section
On Sun, Jun 13, 2010 at 3:28 PM, Nico Schottelius nico-pacman-...@schottelius.org wrote: Signed-off-by: Nico Schottelius n...@kr.ethz.ch --- doc/pacman.8.txt | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) Not inline, but ok, I will just copy/paste below :) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 3d14a42..3175ba5 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -415,6 +415,16 @@ original=X, current=Y, new=Z:: necessary changes into the original file. +Examples + + +pacman -Syu:: + Update package list and upgrade all packages afterwards. + Yeah this is typically the important commands that are not obvious when just quickly browsing the man page. But as I said, it's already covered in the wiki : http://wiki.archlinux.org/index.php/Pacman#Upgrading_packages +pacman -U 'path':: + Install package found in the specified file. + This one looks like the abstract description we already have, just shorter : -U, --upgrade Upgrade or add package(s) to the system and install the required dependencies from sync repos. Either a URL or file path can be specified. This is a “remove-then-add” process. See Upgrade Options below; also see Handling Config Files for an explanation on how pacman takes care of config files.
Re: [pacman-dev] [PATCH 2/2] add example + Files for makepkg
On Sun, Jun 13, 2010 at 3:28 PM, Nico Schottelius nico-pacman-...@schottelius.org wrote: Signed-off-by: Nico Schottelius n...@kr.ethz.ch --- doc/makepkg.8.txt | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) +Examples + +To create a new package from scratch and let makepkg handle md5sums: + + $ mkdir mypkg Maybe you should switch dir to mypkg here + # create PKGBUILD with your favorite editor We already have several links to PKGBUILD man page, maybe we do not need to repeat it here. + $ makepkg -g PKGBUILD You could add a quick one-line description : append integrity checks at the end of the PKGBUILD Note that this is not necessarily md5sums, it depends on the pkgbuild and makepkg.conf : -g, --geninteg For each source file in the source array of PKGBUILD, download the file if required and generate integrity checks. The integrity checks generated are determined by the checks present in the PKGBUILD, falling back to the value of the INTEGRITY_CHECK array in makepkg.conf(5) if these are absent This output can be redirected into your PKGBUILD for source validation using makepkg -g PKGBUILD. + $ makepkg + +Files +- +PKGBUILD:: + Package build description file in the *current* directory. + +
Re: [pacman-dev] [PATCH 1/2] add two entries to pacman manpage examples section
On Sun, Jun 13, 2010 at 3:44 PM, Nico Schottelius nico-pacman-...@schottelius.org wrote: Seems --inline to git send-email wasn't the right then :-/ Ah well, maybe it's just gmail that does not support these inline mails. But if you don't use any arguments, it should work fine by default. +Examples + + +pacman -Syu:: + Update package list and upgrade all packages afterwards. + Yeah this is typically the important commands that are not obvious when just quickly browsing the man page. But as I said, it's already covered in the wiki : http://wiki.archlinux.org/index.php/Pacman#Upgrading_packages Understood. I'm probably stopping my effort right here, if it's agreed that the wiki is the primary documentation for pacman. I'm probably thinking in different context than the typical archlinux-dev, for me it's important software can be re-used at other places and thus I don't think putting how to get used to tool x information into a distribution wiki is a great idea. But again, it may be that my thinking way is not compatible to what you prefer here. Well we try to keep pacman/makepkg as general as possible and avoid distrib specific bits. So it can be re-used on other systems. But the project is still developed by ArchLinux developers for ArchLinux and all resources are hosted on archlinux.org All resources on archlinux.org are available from any systems, fortunately the web is standard enough for that :) Anyway I have nothing against your proposal, I think it's fine, and it's not my call anyway. There is another question : if we want to extend these EXAMPLES section with more stuff from http://wiki.archlinux.org/index.php/Pacman (and maybe http://wiki.archlinux.org/index.php/Pacman_Tips ?), should we put everything in the same man page, or make separate pages ?
Re: [pacman-dev] [PATCH 1/2] add two entries to pacman manpage examples section
On Sun, Jun 13, 2010 at 4:36 PM, Thomas Bächler tho...@archlinux.org wrote: Am 13.06.2010 16:21, schrieb Xavier Chantry: Anyway I have nothing against your proposal, I think it's fine, and it's not my call anyway. I actually like it a lot, too. There is another question : if we want to extend these EXAMPLES section with more stuff from http://wiki.archlinux.org/index.php/Pacman (and maybe http://wiki.archlinux.org/index.php/Pacman_Tips ?), should we put everything in the same man page, or make separate pages ? I think we should not have more than 5 examples there, and only very typical ones, such that a newcomer would pick them up first. You want people to know -Syu, -S, and -U first. Uhm actually I would place -Ss before -U, because it's almost required for -S 1) search with -Ss 2) install with -S 3) upgrade with -Syu 4) install AUR package with makepkg -si (or makepkg -s + pacman -U but I dont use that much) Let's remove all other operations and options which are completely useless :)
