Re: [pacman-dev] (no subject)

[Carson Black]

Sorry, my bad. Still not the most used to submitting patches with git
send-email.

WIll do.

-- Carson Black [ jan Pontaoski ]

Am Fr., 17. Apr. 2020 um 21:34 Uhr schrieb Allan McRae :
>
> On 18/4/20 8:57 am, Carson Black wrote:
> > Thanks for pointing that out; addressed compiler warnings.
> >
>
> Please don't use a cover letter email.   Just edit the patch and put
> comments under the "---" line.
>
> Also, adjust the subject to include "v2" for revised patches.
>
> Allan

Re: [pacman-dev] (no subject)

[Allan McRae]

On 18/4/20 8:57 am, Carson Black wrote:
> Thanks for pointing that out; addressed compiler warnings.
> 

Please don't use a cover letter email.   Just edit the patch and put
comments under the "---" line.

Also, adjust the subject to include "v2" for revised patches.

Allan

[pacman-dev] (no subject)

[Carson Black]

Thanks for pointing that out; addressed compiler warnings.

Re: [pacman-dev] (no subject)

[Eli Schwartz]

On 4/17/20 6:22 PM, Carson Black wrote:
> This asciicast demonstrates the output of this patch: 
> https://asciinema.org/a/321160

Can you use LC_ALL=C for stuff like this? For much the same reason the
patch commit message itself is in English -- if this context helps us
see live what the patch does, and we want to understand it, English is
the generally accepted way to do it.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

[pacman-dev] (no subject)

[Carson Black]

This asciicast demonstrates the output of this patch: 
https://asciinema.org/a/321160

[pacman-dev] (no subject)

[Carson Black]

This should be everything you wanted addressed.

Re: [pacman-dev] (no subject)

[Erich Eckner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 24 Oct 2019, Eli Schwartz wrote:


On 10/24/19 3:28 AM, a...@eckner.net wrote:

Since the update to pacman 5.2.0, `makepkg --printsrcinfo` may emmit
warnings about invalid packager format. However, all config variables in
/etc/makepkg.conf, as well as directory permissions are not relevant if
`--printsrcinfo` is given. So we simply skip the lint_conf and directory
permisison checks then.


The warning about PACKAGER is already fixed on master, by only emitting
the warning when the value is both non-default (by default it is unset
and therefore uses the internal fallback "Unknown Packager") and an
invalid format. So we should no longer have issues when using the stock,
unmodified makepkg.conf -- is it actually worth skipping it entirely?


Ah, right. Sry, I read that, but forgot it when patching the 
release-version of makepkg. Skipping entirely was the least-invasive 
approach I saw. It is by no means necessary (for me).




The directory permission checks skipping argument logically applies to
--packagelist too, and to go one step further, if we're going to have
special handling of this we should also avoid, for example, checking
BUILDDIR when running --verifysource or --geninteg. (But we'd still want
to check SRCDEST, then).

All that being said, the only directory being checked at all is $PWD
unless you've overridden it via your makepkg.conf, in which case I
would've presumed it would be writable. :/


Yes, you're right. I had tested with an all-bogus makepkg.conf (e.g. every 
variable set to some invalid value) to see, whether the variables are 
indeed not needed during --printsrcinfo - and I got tons of directory 
permission errors, so I thought, disabling those made sense, too.


In my opinion, this patch can be dropped.

Btw: sry for the splitted email - I intended to put the text in front of 
the patch email, but apparently, git send-email did something else.




--
Eli Schwartz
Bug Wrangler and Trusted User



Cheers,
Erich

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl2x0YQACgkQCu7JB1Xa
e1pUNg/9GHhL+uMlC/Rvk+eQwZv0dNKwdlAYYGBruLC6qJuU2vuCDjeeQV5t4rhV
yD09hXCOsO/PEUwrnM8nnb/VeZIjEf18w0VYnPqX0NNq85C+F5oyXeQQwATn/rCw
oVcgHsxYTUCShycNIww0dOuzxoRjeUxADPlCj81NxtXwstx22+Xq5VgoWTIC53Sn
9fBmpJh/wI0yqv1uuqWg/3pgs/qYcuhE8shb0AQ54b9sul7XHq/+K+p7odnP4FyI
0oCeeK19sIyJ9IKVFV2uTd+h8C17D8UlxA9OoxE9MJu2CJPMusw/e9SECyc5m7g8
FapMbw+x7MJm+z92o0MfwLxyGec7LeaZpQxGt1M1NpnMFjTwdl1P4itRRRS0tm7W
qa88HU4rIlMu8ZbgID7wqTc7FlE/mGC2Jljg6V/mCy11cwHPLASvkaCKHZPJIIsb
qBIeprk/hY8WT1OtSXdpKur7tKYTrAAxV5Kuts+9Tdd1Iu87UnX4PDiwg2TR4WZi
0Ke1KI3B13pKuTi/IP+k9mCGhpMpk8ruFg36ugdvMoOggtwe6zPIh+gvxknEu5wK
2p40I0zYcExnFimrw7qg4Q/OiLDbWj1bQDoHOf5g0wNFiRDgfHYNDTp5p+0RzzCS
ItNmH2lxdwVPa4fF1GU7SGFv0RP8A2s3m7MWuoEI6jlsNPuRFUQ=
=ul/V
-END PGP SIGNATURE-

Re: [pacman-dev] (no subject)

[Eli Schwartz]

On 10/24/19 3:28 AM, a...@eckner.net wrote:
> Since the update to pacman 5.2.0, `makepkg --printsrcinfo` may emmit 
> warnings about invalid packager format. However, all config variables in 
> /etc/makepkg.conf, as well as directory permissions are not relevant if 
> `--printsrcinfo` is given. So we simply skip the lint_conf and directory 
> permisison checks then.

The warning about PACKAGER is already fixed on master, by only emitting
the warning when the value is both non-default (by default it is unset
and therefore uses the internal fallback "Unknown Packager") and an
invalid format. So we should no longer have issues when using the stock,
unmodified makepkg.conf -- is it actually worth skipping it entirely?

The directory permission checks skipping argument logically applies to
--packagelist too, and to go one step further, if we're going to have
special handling of this we should also avoid, for example, checking
BUILDDIR when running --verifysource or --geninteg. (But we'd still want
to check SRCDEST, then).

All that being said, the only directory being checked at all is $PWD
unless you've overridden it via your makepkg.conf, in which case I
would've presumed it would be writable. :/

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

[pacman-dev] (no subject)

[arch]

Since the update to pacman 5.2.0, `makepkg --printsrcinfo` may emmit 
warnings about invalid packager format. However, all config variables in 
/etc/makepkg.conf, as well as directory permissions are not relevant if 
`--printsrcinfo` is given. So we simply skip the lint_conf and directory 
permisison checks then.

[pacman-dev] (no subject)

[miguel herrera]

Suscribirse

[pacman-dev] (no subject)

[miguel herrera]

Para Aser finanzas chentepanc...@gmail.com

[pacman-dev] (no subject)

[ivy . foster]

For now, I'm just sending in the malloc patch (which, of course, now
only frees variables that exist in the original source, not ones
invented for the previous patches).

To quickly recap an irc conversation with agregory, it looks like
implementing checks before overwriting the db is more complicated if
doing it properly (that is, downloading the newdb to a tempfile,
rather than moving the olddb out of the way and then moving it back if
need be). The downloader curl_download_internal (via _alpm_download)
seems to expect a directory argument, rather than a filename (it
appends the remote filename to the local path).

I'll definitely try the checks patch again, though probably not in the
next couple of days.

Ivy

[pacman-dev] (no subject)

[Andrew Gregory]

>From b3065d8c0a132c4c52707533014e7bc953d501ae Mon Sep 17 00:00:00 2001
Message-Id: 

In-Reply-To: 
References: <1436003967-4737-1-git-send-email-andrew.gregor...@gmail.com>

From: Andrew Gregory 
Date: Sat, 4 Jul 2015 03:35:59 -0400
Subject: [PATCH v2 4/7] wip add hooks

---
 lib/libalpm/Makefile.am |   2 +
 lib/libalpm/alpm.c  |   7 +-
 lib/libalpm/alpm.h  |  10 ++
 lib/libalpm/handle.c|  59 +++
 lib/libalpm/handle.h|   1 +
 lib/libalpm/hook.c  | 443 
 lib/libalpm/hook.h  |  34 
 lib/libalpm/trans.c |   6 +
 8 files changed, 561 insertions(+), 1 deletion(-)
 create mode 100644 lib/libalpm/hook.c
 create mode 100644 lib/libalpm/hook.h

diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am
index f66daed..77e68a4 100644
--- a/lib/libalpm/Makefile.am
+++ b/lib/libalpm/Makefile.am
@@ -42,6 +42,8 @@ libalpm_la_SOURCES = \
graph.h graph.c \
group.h group.c \
handle.h handle.c \
+   hook.h hook.c \
+   ini.h ini.c \
libarchive-compat.h \
log.h log.c \
package.h package.c \
diff --git a/lib/libalpm/alpm.c b/lib/libalpm/alpm.c
index d77b43a..b3f0734 100644
--- a/lib/libalpm/alpm.c
+++ b/lib/libalpm/alpm.c
@@ -49,7 +49,8 @@ alpm_handle_t SYMEXPORT *alpm_initialize(const char *root, 
const char *dbpath,
alpm_errno_t *err)
 {
alpm_errno_t myerr;
-   const char *lf = "db.lck";
+   const char *lf = "db.lck", *syshookdir = "usr/share/alpm/hooks/";
+   char *hookdir;
size_t lockfilelen;
alpm_handle_t *myhandle = _alpm_handle_new();
 
@@ -64,6 +65,10 @@ alpm_handle_t SYMEXPORT *alpm_initialize(const char *root, 
const char *dbpath,
goto cleanup;
}
 
+   MALLOC(hookdir, strlen(myhandle->root) + strlen(syshookdir) + 1, goto 
cleanup);
+   sprintf(hookdir, "%s%s", myhandle->root, syshookdir);
+   myhandle->hookdirs = alpm_list_add(NULL, hookdir);
+
/* set default database extension */
STRDUP(myhandle->dbext, ".db", goto cleanup);
 
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h
index 594f0b6..3049f2f 100644
--- a/lib/libalpm/alpm.h
+++ b/lib/libalpm/alpm.h
@@ -87,6 +87,7 @@ typedef enum _alpm_errno_t {
ALPM_ERR_TRANS_ABORT,
ALPM_ERR_TRANS_TYPE,
ALPM_ERR_TRANS_NOT_LOCKED,
+   ALPM_ERR_TRANS_HOOK_FAILED,
/* Packages */
ALPM_ERR_PKG_NOT_FOUND,
ALPM_ERR_PKG_IGNORED,
@@ -775,6 +776,15 @@ int alpm_option_add_cachedir(alpm_handle_t *handle, const 
char *cachedir);
 int alpm_option_remove_cachedir(alpm_handle_t *handle, const char *cachedir);
 /** @} */
 
+/** @name Accessors to the list of package hook directories.
+ * @{
+ */
+alpm_list_t *alpm_option_get_hookdirs(alpm_handle_t *handle);
+int alpm_option_set_hookdirs(alpm_handle_t *handle, alpm_list_t *hookdirs);
+int alpm_option_add_hookdir(alpm_handle_t *handle, const char *hookdir);
+int alpm_option_remove_hookdir(alpm_handle_t *handle, const char *hookdir);
+/** @} */
+
 /** Returns the logfile name. */
 const char *alpm_option_get_logfile(alpm_handle_t *handle);
 /** Sets the logfile name. */
diff --git a/lib/libalpm/handle.c b/lib/libalpm/handle.c
index a12ac50..98420b0 100644
--- a/lib/libalpm/handle.c
+++ b/lib/libalpm/handle.c
@@ -83,6 +83,7 @@ void _alpm_handle_free(alpm_handle_t *handle)
FREE(handle->dbpath);
FREE(handle->dbext);
FREELIST(handle->cachedirs);
+   FREELIST(handle->hookdirs);
FREE(handle->logfile);
FREE(handle->lockfile);
FREE(handle->arch);
@@ -207,6 +208,12 @@ const char SYMEXPORT *alpm_option_get_dbpath(alpm_handle_t 
*handle)
return handle->dbpath;
 }
 
+alpm_list_t SYMEXPORT *alpm_option_get_hookdirs(alpm_handle_t *handle)
+{
+   CHECK_HANDLE(handle, return NULL);
+   return handle->hookdirs;
+}
+
 alpm_list_t SYMEXPORT *alpm_option_get_cachedirs(alpm_handle_t *handle)
 {
CHECK_HANDLE(handle, return NULL);
@@ -387,6 +394,58 @@ alpm_errno_t _alpm_set_directory_option(const char *value,
return 0;
 }
 
+int SYMEXPORT alpm_option_add_hookdir(alpm_handle_t *handle, const char 
*hookdir)
+{
+   char *newhookdir;
+
+   CHECK_HANDLE(handle, return -1);
+   ASSERT(hookdir != NULL, RET_ERR(handle, ALPM_ERR_WRONG_ARGS, -1));
+
+   newhookdir = canonicalize_path(hookdir);
+   if(!newhookdir) {
+   RET_ERR(handle, ALPM_ERR_MEMORY, -1);
+   }
+   handle->hookdirs = alpm_list_add(handle->hookdirs, newhookdir);
+   _alpm_log(handle, ALPM_LOG_DEBUG, "option 'hookdir' = %s\n", 
newhookdir);
+   return 0;
+}
+
+int SYMEXPORT alpm_option_set_hookdirs(alpm_handle_t *handle, alpm_list_t 
*hookdirs)
+{
+   alpm_list_t 

[pacman-dev] (no subject)

[me]

This was quickly discussed in IRC with others and we saw no reason which would
prevent this from being changed. See the commit message for details.

Note this is my first time contributing to arch/pacman and using
git-send-email, so if there's anything wrong, please let me know!

Re: [pacman-dev] (no subject)

[Florian Bruhin]

* m...@the-compiler.org m...@the-compiler.org [2014-06-05 21:39:44 +0200]:
 
 This was quickly discussed in IRC with others and we saw no reason which would
 prevent this from being changed. See the commit message for details.
 
 Note this is my first time contributing to arch/pacman and using
 git-send-email, so if there's anything wrong, please let me know!

Blergh. This went wrong even more horrible than I thought. If you hate
no-subject mails just as much as I do, my apologizes!

I didn't expect --compose to send a separate mail with the changes, I
thought I was editing the template which then would have the headers
set correctly and the patch appended. In my defense, I did even do a
test run first, just not with --compose. Whoops.

Also, it was pointed out to me I was unclear about discussing it
briefly on IRC - I was referring to #archlinux, not
#archlinux-pacman.

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
 GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


pgpxK0nzi8d2Z.pgp
Description: PGP signature

Re: [pacman-dev] (no subject)

[Allan McRae]

On 03/07/13 00:31, Florian Pritz wrote:
 In your case I'd break this apart into (in roughly that order): detect
 numbered pacsave files (just for locate and find), add quit hotkey,
 prompt for updatedb when using locate, rename DIFFSEARCHPATH (I'm
 not really a fan of that, but for the sake of completeness), improve
 performance/foo by using the pacman db

That is exactly what I was about to reply and ask for.

Thanks,
Allan

Re: [pacman-dev] (no subject)

[Florian Pritz]

On 02.07.2013 05:48, Jonathan Frazier wrote:
   USE_COLOR='y'
   
   m4_include(../scripts/library/output_format.sh) @@ -32,11 +31,19 @@
   m4_include(../scripts/library/term_colors.sh)
   
   usage() { echo $myname : a simple pacnew/pacorig/pacsave updater
   - echo Usage : $myname [-l] -   echo   -l/--locate makes $myname
   use locate rather than find -echo   DIFFPROG variable allows to
   override the default vimdiff -   echo   DIFFSEARCHPATH allows to
   override the default /etc path - echo Example : DIFFPROG=meld
   DIFFSEARCHPATH=\/boot /etc /usr\ $myname + echo  +   echo
   Usage : $myname [-lf] + echo   -l/--locate makes $myname search
   using locate +   echo   -f/--find   makes $myname search using
   find
 
 Add an option for your pacsave method. Maybe -p.
 
 
 Does it make sense to have an option for the default? I don't think so.
 Whatever the default ends up being it doesn't need a option.

I like making defaults have options since it allows to just append 
(default) to the option list and it allows to set an alias that for
example uses locate and sets DIFF_PROG, but you are still able to easily
switch to pacsave without having to change the alias or set DIFF_PROG again.

   }
   
   version() { @@ -45,27 +52,61 @@ version() { echo 'Copyright (C)
   2013 Pacman Development Team pacman-dev@archlinux.org' }
   
  -cmd() { - if [ $locate -eq 1 ]; then -locate -0 -e -b
  \*.pacnew \*.pacorig \*.pacsave -  else -  find $diffsearchpath \(
  -name \*.pacnew -o -name \*.pacorig -o -name \*.pacsave \) -print0 -
  fi -} -
 
 Any reason you moved cmd()? Makes reviewing the changes harder.
 
 
 I was concerned about the scope of the variables it contains. as none
 are not defined at that time. I don't remember if it was necessary or
 just my correcting bad style from writing in other languages.

I believe that if you call a function in bash it doesn't matter where it
was defined, it will always have access to all currently existing global
variables. I don't know how local variables behave, Dave probably does.

 
   if [ $# -gt 0 ]; then case $1 in -l|--locate) -   locate=1;; +
   locate=$(type -P locate);; +  -f|--find) +
  find=$(type -P
   find);;
 
 Why did you change that to do a path lookup and not exit if you can't
 find it?

 
 I didn't think to test if find or locate could not be found. I can add
 that. The idea was to only define a variable for the active search type
 and use that to define the mode later. using the path is convenient.

Not sure what you were after here that find=1 and locate=1 can't provide

 
  +  if [[ ! -r @sysconfdir@/pacman.conf ]]; then
  +  error unable to read @sysconfdir@/pacman.conf
  +  usage; exit 1
  +  fi
  +
  +  eval $(awk '/DBPath/ {print $1$2$3}' @sysconfdir@/pacman.conf)
 
 Make sysconfdir a variable like myver, don't hardcode it directly. (same
 for localstatedir below)
 
 
 This code is what is used in bacman and pacscripts as others requested I
 use as an example. What is the reason to make it a variable?
 
 The only reason I could come up with for making it variable was to
 support running in a alternate root. Adding such support seemed overly
 complex given the current state of pacdiff.
 
 I was thinking of adding this feature after converting the option
 handling to allow options with associated strings. I don't see it as a
 reason to hold up the rest of this code.

Alright, not a big deal, I just like variables better because then you
can look at installed script and see it's not a magic value.

  +  else
  +  # parse local pacman db for backup files and look for pac* 
  based on them
  +  awk '/^%BACKUP%$/ {
  +  while (getline) {
  +  if (/^$/) { nextfile }
  +  print $1
  +  }
  +  }' ${pac_db}/*/files | while read -r bkup; do
  +  check_backup /$bkup.pacnew
  +  check_backup /$bkup.pacorig
  +  for f in /$bkup.pacsave{,.{0..9}}; do
  +  check_backup $f
  +  done
  +  done
  +  fi
  +}
  +
   # see http://mywiki.wooledge.org/BashFAQ/020
   while IFS= read -u 3 -r -d '' pacfile; do
 file=${pacfile%.pac*}
  @@ -82,16 +123,17 @@ while IFS= read -u 3 -r -d '' pacfile; do
 msg2 Files are identical, removing...
 rm -v $pacfile
 else
  -  ask (V)iew, (S)kip, (R)emove %s, (O)verwrite with %s: 
  [v/s/r/o]  $file_type $file_type
  +  ask (V)iew, (S)kip, (R)emove %s, (O)verwrite with %s, (Q)uit: 
  [v/s/r/o/q]  $file_type $file_type
 
 Out of the scope of this patch and IMHO unnecessary (^C is enough).
 
 
 I agree that q is not necessary, but I find it annoying that it is not
 there. I have been thanked for adding it when sharing a previous version
 of this code. At least it shows that that is a reasonable time to quit.
 

[pacman-dev] (no subject)

[Jonathan Frazier]

Subject: re: [pacman-dev] [PATCH] pacdiff using pacman db v2
Reply-To: In-Reply-To:  51d1468a.3030...@xinu.at

On 07/01/13 at 11:06am, Florian Pritz wrote:
 Subject: [pacman-dev] [PATCH] pacdiff using pacman db v2
 
 Please move that v2 into the PATCH tag like so: [PATCH v2]. Otherwise
 it sounds like you use version 2 of the pacman db and it might end
 up in the final commit.
Ok will do.
 
 I'd also suggest to change the subject to something like pacdiff: use
 pacman db for lookups to increase performance so it's more obvious
 what this patch does and why. Still missing the why is using that
 faster/better than locate, but that can be in the commit message.
 
 On 01.07.2013 02:00, Jonathan Frazier wrote:
   Implement the default search using the local pacman db.
 
 I'm not sure the default should switch to an inferior method (inferior
 because it doesn't find everything). updatedb might be too slow on
 certain hardware or whatever, but I think that's a minority so we
 should stick with locate. Also that way long time users won't have
 left over .pacsaves.
 

First let me say that I am not stuck on this being the default option,
but it is the one I will use. I could say locate is inferior because it
finds pacsaves not in use. giving more noise and less signal. My
rational is more that it finds the active configs more throughly. Speed
is not the only factor. I will try and add more descriptive commit msgs.

   Use @sysconfdir@/pacman.conf to find the local db Search for
   pacsave.0 files.
 
 You also search for .pacsave, .pacsave.1, ..., .pacnew, .pacorig. No
 need to mention this explicitly here. Also the comment about
 pacman.conf doesn't belong here unless you explain why you do it this
 way and you have a good reason not to do anything else.
 
 Actually none of the 3 lines explain why any of this is done.
 
 I know these are the changes you made compared to the previous patch,
 but such changes belong to the comment section below (between the
 --- marker and the list of changed files) not into the commit
 message.
 

Adding support for these extra pacsave files is a new feature and worth
noting in the changelog. this feature was requested in another thread. I
can make it a separate patch if the rest of this is going to take longer.

 All I remember (now) is that you do this because updatedb is slow on
 some low end hardware, but that should really be mentioned here
 because I might forget (or am I already wrong? I honestly don't know)
 and others won't even have known in the first place and someone might
 care when they look through the commit log in a few years to find why
 a certain feature appeared (been there, done that).
 

I will try to be more descriptive in my changlog.

  
  Signed-off-by: Jonathan Frazier eyesw...@gmail.com ---
  contrib/pacdiff.sh.in | 86
  ++- 1 file changed,
  64 insertions(+), 22 deletions(-)
  
  diff --git a/contrib/pacdiff.sh.in b/contrib/pacdiff.sh.in index
  47779d6..ee80c9c 100644 --- a/contrib/pacdiff.sh.in +++
  b/contrib/pacdiff.sh.in @@ -21,9 +21,8 @@ declare -r
  myname='pacdiff' declare -r myver='@PACKAGE_VERSION@'
   
  -diffprog=${DIFFPROG:-vimdiff}
  -diffsearchpath=${DIFFSEARCHPATH:-/etc} -locate=0
  +diffprog=${DIFF_PROG:-vimdiff}
  +difffindpath=${DIFF_FIND_PATH:-/etc}
 
 Out of scope of this patch.
 

DIFFSEARCHPATH is misleading and I find it difficult to read. the old name
implies it works for all search types, when it only applied to find.
Since nobody is defending find as the default, it should be changed
along with the default. Adding underscores was just cause I am fixing
it. Is DIFFFINDPATH more acceptable?

   USE_COLOR='y'
   
   m4_include(../scripts/library/output_format.sh) @@ -32,11 +31,19 @@
   m4_include(../scripts/library/term_colors.sh)
   
   usage() { echo $myname : a simple pacnew/pacorig/pacsave updater
   -  echo Usage : $myname [-l] -   echo   -l/--locate makes $myname
   use locate rather than find - echo   DIFFPROG variable allows to
   override the default vimdiff -echo   DIFFSEARCHPATH allows to
   override the default /etc path -  echo Example : DIFFPROG=meld
   DIFFSEARCHPATH=\/boot /etc /usr\ $myname +  echo  +   echo
   Usage : $myname [-lf] +  echo   -l/--locate makes $myname search
   using locate +echo   -f/--find   makes $myname search using
   find
 
 Add an option for your pacsave method. Maybe -p.
 

Does it make sense to have an option for the default? I don't think so.
Whatever the default ends up being it doesn't need a option.

  +   echo  +   echo Note: the default search looks for backup files in
  the local pacman db +  echo   this generally will not find
  *.pacsave files +  echo  +   echo   DIFF_PROG variable will
  override the default editor: vimdiff + echo   DIFF_FIND_PATH will
  override the default path when using --find +  echo  +   echo
  Example : DIFF_PROG=meld $myname +echo Example

[pacman-dev] (no subject)

[Dave Reisner]

The ensuing patches revert Allan's breakage^Wchanges to the public API with
regard to the introduction of pmpkghash_t. Since we haven't exposed any public
facing API calls which can manipulate a pmpkghash_t, there's not much point
in exposing the type along with it. alpm_db_get_pkgcache_list is renamed back
to alpm_db_get_pkgcache, and the calls which return a pmpkghash_t are explicitly
renamed alpm_db_get_pkgcache_hash.

dave

Re: [pacman-dev] (no subject)

[Allan McRae]

On 26/02/11 00:29, Dave Reisner wrote:


The ensuing patches revert Allan's breakage^Wchanges to the public API with
regard to the introduction of pmpkghash_t. Since we haven't exposed any public
facing API calls which can manipulate a pmpkghash_t   snip


Yet...  There are several places in pacman where the exposing (e.g.) 
_alpm_pkghash_find() would be very useful so I think this is likely to 
be exposed in the future.


Allan

Re: [pacman-dev] (no subject)

[Dan McGee]

On Friday, February 25, 2011, Allan McRae al...@archlinux.org wrote:
 On 26/02/11 00:29, Dave Reisner wrote:


 The ensuing patches revert Allan's breakage^Wchanges to the public API with
 regard to the introduction of pmpkghash_t. Since we haven't exposed any public
 facing API calls which can manipulate a pmpkghash_t   snip


 Yet...  There are several places in pacman where the exposing (e.g.) 
 _alpm_pkghash_find() would be very useful so I think this is likely to be 
 exposed in the future.

You can blame this on me, Allan. I suggested we do this because we
have caused headaches to people with the unnecessary rename. Exposing
it later via a _hash suffix might happen, but no need to expose it
until we know it is needed.

-Dan

Re: [pacman-dev] (no subject)

[Allan McRae]

On 26/02/11 01:06, Dan McGee wrote:

On Friday, February 25, 2011, Allan McRaeal...@archlinux.org  wrote:

On 26/02/11 00:29, Dave Reisner wrote:


The ensuing patches revert Allan's breakage^Wchanges to the public API with
regard to the introduction of pmpkghash_t. Since we haven't exposed any public
facing API calls which can manipulate a pmpkghash_tsnip


Yet...  There are several places in pacman where the exposing (e.g.) 
_alpm_pkghash_find() would be very useful so I think this is likely to be 
exposed in the future.


You can blame this on me, Allan. I suggested we do this because we
have caused headaches to people with the unnecessary rename. Exposing
it later via a _hash suffix might happen, but no need to expose it
until we know it is needed.



OK.  Ack both patches then.

Allan

[pacman-dev] (no subject)

[Nico Schottelius]

Next try, with more options and fixed makepkg variant.