Re: [pacman-dev] (no subject)
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)
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)
Sure, I'll keep that in mind for the future. -- Carson Black [ jan Pontaoski ] Am Fr., 17. Apr. 2020 um 18:33 Uhr schrieb 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 >
[pacman-dev] (no subject)
Thanks for pointing that out; addressed compiler warnings.
Re: [pacman-dev] (no subject)
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)
This asciicast demonstrates the output of this patch: https://asciinema.org/a/321160
[pacman-dev] (no subject)
This should be everything you wanted addressed.
Re: [pacman-dev] (no subject)
-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)
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)
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)
Suscribirse
[pacman-dev] (no subject)
Para Aser finanzas chentepanc...@gmail.com
[pacman-dev] (no subject)
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)
>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 *i; + CHECK_HANDLE(handle, return -1); + if(handle->hookdirs) { + FREELIST(handle->hookdirs); + } + for(i = hookdirs; i; i = i->next) { + int ret = alpm_option_a
Re: [pacman-dev] (no subject)
* 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
[pacman-dev] (no subject)
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)
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)
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 ' } >> > >> > -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
[pacman-dev] (no subject)
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 --- > > 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
Re: [pacman-dev] (no subject)
On 26/02/11 01:06, Dan McGee wrote: On Friday, February 25, 2011, Allan McRae 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 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
Re: [pacman-dev] (no subject)
On Friday, February 25, 2011, Allan McRae 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 > > > 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)
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 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
[pacman-dev] (no subject)
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
[pacman-dev] (no subject)
Next try, with more options and fixed makepkg variant.