Re: [pacman-dev] Repository management
Xyne wrote: >Obviously there will be some redundancy in the up to 3 copies of >-.db but I think that's better than e.g. breaking pkgfile >searches after an upgrade. Just to expand on that, the worst case scenario leads to the same level of redundancy as we currently have with complete *.files databases, while the best case leads to no redundancy, all the while preserving the independence of pacman -S... and pacman -F... (and whatever else you want to add). >With this approach you could also download the latest version of the sync >databases as -.db without symlinking .db to it, and then >use that to query upgradable packages and other info from the mirror. To make that work with my suggestion for cleaning up old timestamped databases, add a symlink named e.g. .future, .next or .remote. That could be used by e.g. checkupdates or pre-emptive package downloading scripts. There may even be cases where the cleanup is unwanted, such as for a script that regularly downloads databases and upgradable packages to provide an incremental upgrade path at a later date (obviously regular updates are preferred, but maybe useful and reasonable in some rare cases). In my previous reply, I had forgotten that pacman -Sc prompts for the database and pkgcache cleanups independently. Forget what I said about automatic cleanups. Offload that to pacman -Sc. Regards, Xyne
Re: [pacman-dev] Repository management
On 2017-05-09 22:54 +1000 Allan McRae wrote: >I am looking for ideas here. Please brainstorm to your hearts content. Ok :) >So two points up for discussion: > > >1) Sync repository layout? I don't see any point in leaving the tar >based format, as reading of sync databases is not a bottleneck. (The >local db format can be a bottleneck, but that is a separate discussion...) > >Do we split the information in .db out of .files and add a .full db with >complete information? Then any .src db could follow suit and just have >source package information. How do we get around the out of sync issue >(e.g., a package is removed from .db, but we have an old .files database >with it). Do we add timestamps, and print a warning on -F operations >when the two are out of sync? Add a timestamp inside each database (*.db, *.files, *.src). When pacman downloads a database, instead of saving it as . and squashing the previous database, save it as -.. Each refresh operation (pacman -Sy, pacman -Fy) is associated with a particular database (*.db and *.files, respectively). Create an untimestamped symlink to that database, e.g. $ pacman -Sy... # retrieve .db and save as -.db # ln -s -.db .db $ pacman -Fy... # retrieve .db and save as -.db # retrieve .files and save as -.files # ln -s -.files .files # something similar for *.src files For operations that only involve the current .db files, no change is needed for loading the database. For loading .files, you will need to dereference .files first, grab from -.files in the example above, and then use it to load -.db instead of .db. Same method for *.src files. For cleanup of the timestamped files, collect the valid timestamps from the untimestamped symlinks and then remove anything that doesn't match them. This should probably be done with each database refresh. Maybe you can use the same function that you use to clean up the package cache with -Sc while leaving installed packages. Obviously there will be some redundancy in the up to 3 copies of -.db but I think that's better than e.g. breaking pkgfile searches after an upgrade. With this approach you could also download the latest version of the sync databases as -.db without symlinking .db to it, and then use that to query upgradable packages and other info from the mirror. For propagating the database to the servers, nothing changes. Whenever the database is updated, generate .db, .files, .src and whatever else at the same time with the same internal timestamp and then just push them out as usual. >2) Do we need a better (read "more easily maintainable") tool for >handling database generation and updates? libalpm already can read in >information package files, so we could add libalpm/db_write.c with the >database creation functions. Should we unify our repo format with our >local database format which we already write? Yes for unification, preferably in a standardized format (e.g. yaml). Having the functionality to read and write the files in libalpm would be useful for third-party tool developers. On 2017-05-10 12:54 -0400 Dave Reisner wrote: >WRT replacing repo-add, I'd suggest we come up with a the use cases we >want to support, design an interface to meet them, and then come up with >the implementation. Might be nice to start with the Arch Linux >repository layout as an example that we'd want to support (pooled >packages with symlinks into repo dirs). What about using a relative subpath instead of a filename in the database. That would enable transparent freeform repo layouts (e.g. pooled packages without symlinks, package groups in different subdirs, etc.). You could also avoid the need for subdirectories by adding the architecture to the database filename, e.g. .. To simplify repo-add, you could include .SRCINFO directly to avoid parsing and reformatting/rewriting that metadata. Keep it as a separate file then add a new one (call it PKGINFO?) for information about the *.pkg.* file itself (build date, packager, signature, checksum, size, relative filepath, etc.). Add other files to contain related information (e.g. INSTALLINFO with install time, file list, install origin?). That way, each step copies existing files and adds a new one with the new info (repo-add: collect SRCINFO, add PKGINFO; install a package: copy SRCINFO AND PKGINFO to local db, create INSTALLINFO etc.) A repo metadata file would also be required in the root directory with the repo timestamp for the timestamped databases described above. The file could also collect other metadata such as package providers and maybe replacements to speed up some operations. Regards, Xyne
Re: [pacman-dev] Pacman configuration parser library
On 2017-01-04 08:54 +0100 Jelle van der Waa wrote: >Interesting, are you using CFFI or are you generating C code for >CPython? The latter, via the Python/C API [1]. I'm probably re-inventing wheels as I go. [1] https://docs.python.org/3/c-api/index.html
Re: [pacman-dev] Pacman configuration parser library
On 2017-01-02 19:58 +0100 Jelle van der Waa wrote: >I'd like to chime in that I would love to see pyalpm to stop using it's >self written config parser. I've put it on my TODO list, but I'm not >sure when I'll be able to look at it. At the risk of it becoming vaporware, I'm working on this right now. I already have a working shared library for src/pacman/conf.h (via CMake) and the beginnings of a Python extension module for working with it (so far it only includes a wrapper around "parseconfig" and a class for config_repo_t). As I was writing that module I realized that I need most of alpm so I've started writing my own Python module for that too. I'm using scripts to automatically generate code for all of the enums and structs to ensure uniformity. The idea is to provide a module with a 1-to-1 correspondence with alpm.h (all enums as globals, classes for each struct, identical function names) along with utility modules for convenience code (e.g. convert enums to strings). This will make it much easier to maintain. I'm not forking pyalpm because a) I'm using this as a learning experience and prefer to do it from scratch and b) I'm adopting a different approach. I'll make an announcement here once it's released. Regards, Xyne
[pacman-dev] makepkg: key verification error
Hi, There is a seemingly unending trickle of user comments on the AUR seeking advice about key verification errors when building packages. The error message in question is ... FAILED (unknown public key ...) ==> ERROR: One or more PGP signatures could not be verified! Would you consider changing this message to make it clear to the user that they key is not in the *user's* keyring? Maybe something like (key ... not found in user's keyring: you may need to import it). The current message seems to leave a lot of users thinking that the key and signature are shady and untrusted. Regards, Xyne p.s. I still hope that you will re-introduce the --pkg option or an alternative to selectively install split packages with "-i". (Building them all makes sense. Giving no option but to install them all, not so much.) I can provide a package for this as I keep a working patched version of makepkg for this purpose (and provide it in a package for others).
Re: [pacman-dev] makepkg --pkg for selective installation of split packages
>Any change *chance*
Re: [pacman-dev] makepkg --pkg for selective installation of split packages
On 2016-02-15 15:05 +1000
Allan McRae wrote:
>No chance the full patch will be accepted. But the changing PACMAN_OPTS
>to an array should probably be done.
Here's a patch for converting PACMAN_OPTS to an array (if this list accepts
attachments). I'll post a link if not.
Any change of getting --pkg restored just for selecting which package to
install? It would only affect the package loop in the "install_package"
function. Incidentally, "pkg:" is still in the OPT_LONG array.--- makepkg.orig 2016-02-15 22:13:16.930571029 +
+++ makepkg 2016-02-15 22:14:52.888596176 +
@@ -87,7 +87,7 @@
SOURCEONLY=0
VERIFYSOURCE=0
-PACMAN_OPTS=
+PACMAN_OPTS=()
shopt -s extglob
@@ -219,7 +219,7 @@
run_pacman() {
local cmd
if [[ $1 != -@(T|Qq) ]]; then
- cmd=("$PACMAN_PATH" $PACMAN_OPTS "$@")
+ cmd=("$PACMAN_PATH" "${PACMAN_OPTS[@]}" "$@")
else
cmd=("$PACMAN_PATH" "$@")
fi
@@ -1926,8 +1926,8 @@
# Pacman Options
--asdeps) ASDEPS=1;;
--needed) NEEDED=1;;
- --noconfirm) PACMAN_OPTS+=" --noconfirm" ;;
- --noprogressbar) PACMAN_OPTS+=" --noprogressbar" ;;
+ --noconfirm) PACMAN_OPTS+=(--noconfirm) ;;
+ --noprogressbar) PACMAN_OPTS+=(--noprogressbar) ;;
# Makepkg Options
--allsource) SOURCEONLY=2 ;;
@@ -1945,7 +1945,7 @@
-i|--install) INSTALL=1 ;;
--key)shift; GPGKEY=$1 ;;
-L|--log) LOGGING=1 ;;
- -m|--nocolor) USE_COLOR='n'; PACMAN_OPTS+=" --color never" ;;
+ -m|--nocolor) USE_COLOR='n'; PACMAN_OPTS+=(--color never) ;;
--noarchive) NOARCHIVE=1 ;;
--nocheck)RUN_CHECK='n' ;;
--noprepare) RUN_PREPARE='n' ;;
Re: [pacman-dev] makepkg --pkg for selective installation of split packages
Just to follow up, I came to the conclusion that there is no viable workaround for all scenarios (e.g. when PKGDEST is set) so I ended up patching makepkg to restore the --pkg option. It only affects the installation. I also added the option "--pconfig" to pass a custom configuration file to pacman (which required changing PACMAN_OPTS to an array to avoid potential word expansion). The patch is small. If anyone is interested, you can find it in the current bauerbill source tarball [1]. If there is a chance of inclusion upstream then I can rework it and submit it as a Git patch. [1] http://xyne.archlinux.ca/projects/bauerbill/src/bauerbill-2016.2.15.tar.xz
Re: [pacman-dev] makepkg --pkg for selective installation of split packages
On 2016-02-14 21:37 + Xyne wrote: >On 2016-02-14 15:31 -0500 >Dave Reisner wrote: > >>Note that you can now also use makepkg to list the names of the packages >>that it would generate, using the --packagelist flag. > >I am going to use that as a workaround but even after splitting apart the >components (pkgname, pkgver, arch) and making sure that the name matches, it >will require assumptions about the package archive extension (or sourcing of >makepkg.conf, but that requires knowledge of which makepkg.conf was used to be >rigorous). Nothing comes close to the cleanliness of the --pkg option. > >Incidentally, that option was also useful to avoid storing unwanted packages at >PKGDEST. Implementing the workaround right now I've noticed that another issue with the separate invocation of pacman -U is that any dependencies installed via "makepkg -rs" are removed and then re-installed during installation with pacman, while omitting "-r" will leave makedeps.
[pacman-dev] makepkg --pkg for selective installation of split packages
Hi, I completely missed the discussion in September about removing the "--pkg" option from makepkg. Without that option, "makepkg -irs" can only be used to install all packages from a split PKGBUILD, but a user often wants to install just one package (e.g [1]). Makepkg's automatic dependency resolution and installation is very useful for automation, and scripting "pacman -U" requires assumptions about expected package names that are likely error-prone and thus not a viable alternative. I opened a bug report about this before seeing the thread. I bring it up here for further discussion as this is where its removal was discussed. Regards, Xyne [1] https://bbs.archlinux.org/viewtopic.php?pid=1604418#p1604418
Re: [pacman-dev] makepkg --pkg for selective installation of split packages
On 2016-02-14 15:31 -0500 Dave Reisner wrote: >Note that you can now also use makepkg to list the names of the packages >that it would generate, using the --packagelist flag. I am going to use that as a workaround but even after splitting apart the components (pkgname, pkgver, arch) and making sure that the name matches, it will require assumptions about the package archive extension (or sourcing of makepkg.conf, but that requires knowledge of which makepkg.conf was used to be rigorous). Nothing comes close to the cleanliness of the --pkg option. Incidentally, that option was also useful to avoid storing unwanted packages at PKGDEST.
Re: [pacman-dev] makepkg --pkg for selective installation of split packages
>Implementing the workaround right now I've noticed that another issue with the >separate invocation of pacman -U is that any dependencies installed via >"makepkg -rs" are removed and then re-installed during installation with >pacman, while omitting "-r" will leave makedeps. Another annoying point: makepkg -rs with DESTDIR detects previously built packages but no longer recreates the symlink in the working directory so any subsequent pacman -U command needs to determine where the DESTDIR is and install from there.
Re: [pacman-dev] makepkg --pkg for selective installation of split packages
>> Implementing the workaround right now I've noticed that another issue with >> the separate invocation of pacman -U is that any dependencies installed via >> "makepkg -rs" are removed and then re-installed during installation with >> pacman, while omitting "-r" will leave makedeps. >> > >pamcan -U deals with dependency resolution. Yeah, but lets say you want to install foo with depends=(bar baz lulu) makedepends=(this that whatever) makepkg -rs installs bar, baz, lulu, this, that and whatever, builds the package, then removes all of them. Subsequent pacman -U then re-installs bar, baz, and lulu. Even if the packages are small with no side-effects via install scripts, that is inefficient. If they are large and/or have side-effects (e.g. updating system databases, font caches, etc) then it is very inefficient.
Re: [pacman-dev] [PATCH] Added mirror support to makepkg's source array.
On 2013-11-18 12:09 +1000 Allan McRae wrote: What did you think about the proposal in an earlier reply to this thread: source=(mirror://_foo/blah/blah/foo.tar.gz) _foo=(http://foo.com/; http://bar.com/;) I think we can bet safely that mirror:// will not become a valid protocol. And we are replacing the start of the URL so just using the initial / as the delimiter is fine. Allan That works, but I would prefer differential syntax to prevent confusion with regular URLs. MIRROR:// should be enough. It stands out, and we already use upper-case for SKIP in the checksums array, so I think it is stylistically coherent. Regards, Xyne
Re: [pacman-dev] [PATCH] Added mirror support to makepkg's source array.
On 2013-11-15 21:06 +1000 Allan McRae wrote: An idea is doing: source=(mirror://file.tar.gz) mirror=(http://foo.com/; http://bar.com/;) makepkg would replace mirror:// in the source line with a value from the mirror array and try downloading from each one until success or total failure. To allow multiple sources to have different mirrors, I am proposing we detect an unknown protocol in the url and look for the corresponding array. e.g. we could have source=(sourceforge://file.tar.gz) and look for the sourceforge array. Comments or other ideas? Detecting unknown protocols is not future proof and will lead to an easy but never-ending game of whack-a-mole. It would also lead to unnecessary repetition in the mirror array. I think it would be better to use a variable delimiter (possibly an illegal URL character, or a PKGBUILD-variable for maximum flexibility), e.g. source_delim='*' source=(http://*mirror*file.tar.gz;) mirror=(foo.com/ bar.com/) You could even use source_ as a prefix for the source variables to avoid namespace polution (source_mirror, source_foo, etc). Allowing variables at arbitrary points provides greater flexibility and reduces verbosity (e.g. the repetition of the scheme in this case). If you really want to limit this to URL prefixes, then I suggest enforcing a policy of using lower-case schemes for regular URLs and upper-case pseudo-schemes for mirrors, e.g. source=(MIRROR://file.tar.gz) MIRROR=(http://foo.com/; http://bar.com/;) While I think the previous approach is better, this would also avoid the eventual grief of a hard-coded list of recognized protocols. Incidentally, if you generalize this enough you could probably re-use the code to implement dependency alternatives, if you are interested in that. The logic overlaps. Regards, Xyne
[pacman-dev] [PATCH 2/3] bacman: update copyright information in version function
---
contrib/bacman.sh.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/bacman.sh.in b/contrib/bacman.sh.in
index 30db686..ca4d88d 100644
--- a/contrib/bacman.sh.in
+++ b/contrib/bacman.sh.in
@@ -44,6 +44,7 @@ usage() {
version() {
printf %s %s\n $myname $myver
echo 'Copyright (C) 2008 locci carlocci_at_gmail_dot_com'
+ echo 'Copyright (C) 2008-2013 Pacman Development Team
pacman-dev@archlinux.org'
}
if [[ $1 == --nocolor ]]; then
--
1.8.4
[pacman-dev] [PATCH 3/3] bacman: optionally include unmodified backup files when available
---
contrib/bacman.sh.in | 80 ++--
1 file changed, 59 insertions(+), 21 deletions(-)
diff --git a/contrib/bacman.sh.in b/contrib/bacman.sh.in
index ca4d88d..5d2210a 100644
--- a/contrib/bacman.sh.in
+++ b/contrib/bacman.sh.in
@@ -27,6 +27,7 @@ shopt -s nullglob
declare -r myname='bacman'
declare -r myver='@PACKAGE_VERSION@'
USE_COLOR='y'
+INCLUDE_PACNEW='n'
# Required for fakeroot because options are shifted off the array.
ARGS=($@)
@@ -37,7 +38,7 @@ m4_include(../scripts/library/output_format.sh)
#
usage() {
echo This program recreates a package using pacman's db and system
files
- echo Usage: $myname [--nocolor] installed package name
+ echo Usage: $myname [--nocolor] [--pacnew] installed package name
echo Example: $myname kernel26
}
@@ -47,10 +48,17 @@ version() {
echo 'Copyright (C) 2008-2013 Pacman Development Team
pacman-dev@archlinux.org'
}
-if [[ $1 == --nocolor ]]; then
- USE_COLOR='n'
- shift
-fi
+while [[ ! -z $1 ]]; do
+ if [[ $1 == --nocolor ]]; then
+ USE_COLOR='n'
+ shift
+ elif [[ $1 == --pacnew ]]; then
+ INCLUDE_PACNEW='y'
+ shift
+ else
+ break
+ fi
+done
m4_include(../scripts/library/term_colors.sh)
@@ -143,7 +151,6 @@ cd $work_dir || exit 1
#
msg2 Copying package files...
-cat $pkg_dir/files |
while read i; do
if [[ -z $i ]]; then
continue
@@ -156,24 +163,55 @@ while read i; do
case $current in
%FILES%)
- ret=0
- if [[ -e /$i ]]; then
- bsdtar -cnf - /$i 2 /dev/null | bsdtar -xpf -
-
- # Workaround to bsdtar not reporting a missing
file as an error
- if ! [[ -e $work_dir/$i || -L $work_dir/$i ]];
then
- error unable to add /$i to the package
- plainIf your user does not
have permssion to read this file then
- plainyou will need to run
$myname as root
- rm -rf $work_dir
- exit 1
+ local_file=/$i
+ package_file=$work_dir/$i
+
+ if [[ ! -e $local_file ]]; then
+ warning package file $local_file is missing
+ continue
+ fi
+ ;;
+
+ %BACKUP%)
+ # Get the MD5 checksum.
+ original_md5=${i##*$'\t'}
+ # Strip the md5sum after the tab.
+ i=${i%$'\t'*}
+ local_file=/$i.pacnew
+ package_file=$work_dir/$i
+
+ # Include unmodified .pacnew files.
+ local_md5=$(md5sum $local_file | cut -d' ' -f1)
+ if [[ $INCLUDE_PACNEW == 'n' ]] \
+ || [[ ! -e $local_file ]] \
+ || [[ $local_md5 != $original_md5 ]]; then
+ # Warn about modified files.
+ local_md5=$(md5sum /$i | cut -d' ' -f1)
+ if [[ $local_md5 != $original_md5 ]]; then
+ warning package file /$i has been
modified
fi
- else
- warning package file /$i is missing
+ # Let the normal file be included in the
%FILES% list.
+ continue
fi
;;
+
+ *)
+ continue
+ ;;
esac
-done
+
+ ret=0
+ bsdtar -cnf - -s'/.pacnew$//' $local_file 2 /dev/null | bsdtar -xpf
- 2 /dev/null
+
+ # Workaround to bsdtar not reporting a missing file as an error
+ if ! [[ -e $package_file || -L $package_file ]]; then
+ error unable to add $local_file to the package
+ plainIf your user does not have permission to read
this file then
+ plainyou will need to run $myname as root
+ rm -rf $work_dir
+ exit 1
+ fi
+done $pkg_dir/files
ret=$?
if (( ret )); then
@@ -256,7 +294,7 @@ while read i; do
# files
%BACKUP%)
- # strip the md5sum after the tab
+ # Strip the md5sum after the tab
echo backup = ${i%%$'\t'*}.PKGINFO
;;
esac
--
1.8.4
[pacman-dev] [PATCH 0/3] bacman: include BACKUP files and minor fixes
Take 2. The previous patch has been split in 3. All of Allan's suggestions have been included. Xyne (3): bacman: pass unshifted arguments to fakeroot bacman: update copyright information in version function bacman: optionally include unmodified backup files when available contrib/bacman.sh.in | 85 ++-- 1 file changed, 63 insertions(+), 22 deletions(-) -- 1.8.4
[pacman-dev] [PATCH 1/3] bacman: pass unshifted arguments to fakeroot
---
contrib/bacman.sh.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/bacman.sh.in b/contrib/bacman.sh.in
index 5435e40..30db686 100644
--- a/contrib/bacman.sh.in
+++ b/contrib/bacman.sh.in
@@ -27,6 +27,8 @@ shopt -s nullglob
declare -r myname='bacman'
declare -r myver='@PACKAGE_VERSION@'
USE_COLOR='y'
+# Required for fakeroot because options are shifted off the array.
+ARGS=($@)
m4_include(../scripts/library/output_format.sh)
@@ -71,7 +73,7 @@ if (( EUID )); then
if [[ -f /usr/bin/fakeroot ]]; then
msg Entering fakeroot environment
export INFAKEROOT=1
- /usr/bin/fakeroot -u -- $0 $@
+ /usr/bin/fakeroot -u -- $0 ${ARGS[@]}
exit $?
else
warning installing fakeroot or running $myname as root is
required to
--
1.8.4
Re: [pacman-dev] [PATCH] updpkgsums: omit downloader output when capturing checksums
Xyne wrote:
{
+ # Download sources first to avoid downloader output in newsums array
below.
+ makepkg --verifysource -dp $buildfile /dev/null 21
+
I could not find a combination of makepkg options that would omit nonsensical
warnings and irrelevant output, so I have redirected everything to /dev/null.
This is not ideal because the user may be left wondering what's happening as
the sources are downloaded, but the output is confusing otherwise.
Using -g leads to the least output but that will lead to redundant
calculations of the checksums. The best approach would probably be to redirect
downloader output to stderr in makepkg proper when invoked with -g, which would
avoid this issue entirely.
Thoughts?
Re: [pacman-dev] [PATCH] updpkgsums: omit downloader output when capturing checksums
Dave Reisner wrote: Can you explain more about how you ran into this? I use aria2c as a downloader. If the sources are not already present then I end up with the full output of aria2c in the PKGBUILD above the checksums.
[pacman-dev] [PATCH] makepkg: redirect downloader output to STDERR when generating checksums
--- scripts/makepkg.sh.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index d0951df..406b2c9 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -2825,7 +2825,8 @@ if (( GENINTEG )); then mkdir -p $srcdir chmod a-s $srcdir cd_safe $srcdir - download_sources fast + # Redirect downloader output so that scripts can capture the checksum output. + download_sources fast 12 generate_checksums exit 0 # $E_OK fi -- 1.8.4
[pacman-dev] [PATCH] makepkg: include all hash types in integlist
---
scripts/makepkg.sh.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index d0951df..6b5a193 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -1133,7 +1133,7 @@ generate_checksums() {
local integlist
if (( $# == 0 )); then
- IFS=$'\n' read -ra integlist (get_integlist)
+ IFS=$'\n' integlist=($(get_integlist))
else
integlist=($@)
fi
--
1.8.4
Re: [pacman-dev] [PATCH] makepkg: include all hash types in integlist
On 2013-09-17 15:18 +
Xyne wrote:
---
scripts/makepkg.sh.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index d0951df..6b5a193 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -1133,7 +1133,7 @@ generate_checksums() {
local integlist
if (( $# == 0 )); then
- IFS=$'\n' read -ra integlist (get_integlist)
+ IFS=$'\n' integlist=($(get_integlist))
else
integlist=($@)
fi
--
1.8.4
Without this only the first checksum is included in the output of makepkg -g.
[pacman-dev] [PATCH] makepkg: include all hash types in integlist
---
scripts/makepkg.sh.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index d0951df..0d72794 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -1133,7 +1133,7 @@ generate_checksums() {
local integlist
if (( $# == 0 )); then
- IFS=$'\n' read -ra integlist (get_integlist)
+ IFS=$'\n' read -rd '' -a integlist (get_integlist)
else
integlist=($@)
fi
--
1.8.4
Re: [pacman-dev] [PATCH] updpkgsums: omit downloader output when capturing checksums
Allan McRae wrote:
Try this change in download_file in makepkg:
- eval $dlcmd || ret=\$?
+ eval $dlcmd 2 || ret=\$?
If that is good, send a patch.
I sent another patch just before getting this. I used the same approach, but I
redirected the output of the call to download_sources in the conditional
GENINTEG block.
Let me know if you still want me to move it to the download_file function and
I'll resubmit.
Incidentally, when I build makepkg locally and run makepkg -g it only outputs
the first checksum array if multiple are present (e.g. if the PKGBUILD
contains sha256sums and md5sums, in that order, it only outputs sha256sums). At
first I thought it was due to something I had done, but it happens even with the
current master branch. I've triple-checked this but I'm still expecting it to
be my fault.
I'm building with
./autogen.sh
# From pacman PKGBUILD
./configure --prefix=/usr --sysconfdir=/etc \
--localstatedir=/var --enable-doc \
--with-scriptlet-shell=/usr/bin/bash \
--with-ldconfig=/usr/bin/ldconfig
make
make -C contrib
Can someone else check this? Using the powerpill PKGBUILD [1] I only get this:
== Retrieving sources...
- Found powerpill-2013.7.25.tar.xz
- Found powerpill-2013.7.25.tar.xz.sig
== Generating checksums for source files...
md5sums=('280b69b951a6e309a18897d7bdb1394c'
'SKIP')
[1] http://xyne.archlinux.ca/projects/powerpill/pkgbuild/PKGBUILD
Re: [pacman-dev] [PATCH] makepkg: include all hash types in integlist
On 2013-09-17 11:31 -0400 Dave Reisner wrote: On Tue, Sep 17, 2013 at 03:28:31PM +, Xyne wrote: Dave Reisner wrote: This isn't the right fix. It should be: IFS=$'\n' read -rd '' -a integlist (get_integlist) else integlist=($@) fi Out of curiosity, what difference does it make? Is subshell invocation more expensive than file substitution? It's a reliance on word expansion (and the side effects that potentially come with it) versus just reading the data as is. Using read is about being correct, not about cost. With IFS set to newline, there will be no unintentional word expansion in either case. The results are the same. I do not see how one approach is more correct than the other. Note that I have submitted a patch with your recommended fix (it's your code after all).
Re: [pacman-dev] [PATCH] updpkgsums: omit downloader output when capturing checksums
On 2013-09-17 14:56 + Incidentally, when I build makepkg locally and run makepkg -g it only outputs the first checksum array if multiple are present (e.g. if the PKGBUILD contains sha256sums and md5sums, in that order, it only outputs sha256sums). Make that it only seems to output the first checksum array after sorting them.
[pacman-dev] [PATCH] makepkg: redirect downloader output to STDERR
This allows scripts to safely capture the output of makepkg -g.
---
scripts/makepkg.sh.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index d0951df..b0086a3 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -372,7 +372,7 @@ download_file() {
fi
local ret=0
- eval $dlcmd || ret=\$?
+ eval $dlcmd 2 || ret=\$?
if (( ret )); then
[[ ! -s $dlfile ]] rm -f -- $dlfile
error $(gettext Failure while downloading %s) $filename
--
1.8.4
[pacman-dev] Bacman patch
Hi, I have updated bacman with the following changes: * added option --pacnew to include unmodified .pacnew BACKUP files in package archive when available (instead of locally modified version) * added warning when modified BACKUP files are included * fixed bug in fakeroot invocation (fakeroot was invoked with shifted argument array, so the --nocolor (and --pacnew) options were lost * removed one unnecessary cat file | I cloned the pacman git repo to format a patch, but pacman/contrib/bacman.sh.in appears to be outdated (e.g. the shebang is still #!/bin/bash, even though the current bacman uses #!/usr/bin/bash). So, where is the current bacman source? Regards, Xyne
[pacman-dev] [PATCH] bacman: include BACKUP files
Here is the patch with the aforementioned changes. This allows the optional creation of packages with the unmodified pacnew files when they are available. This is the first time that I'm using git send-email. Let me know what I need to fix if anything is incorrect. Xyne (1): bacman: optionally include unmodified BACKUP files and fix other errors contrib/bacman.sh.in | 85 ++-- 1 file changed, 63 insertions(+), 22 deletions(-) -- 1.8.4
[pacman-dev] [PATCH] bacman: optionally include unmodified BACKUP files and fix other errors
Add option --pacnew to include unmodified .pacnew BACKUP files in package
archive when available (instead of locally modified version).
Add warning when modified BACKUP files are included.
Fix bug in fakeroot invocation. During argument parsing, option flags are
shifted off of the argument array. This shifted array was previously passed to
fakeroot resulting in the omission of options such as --nocolor. Avoid this by
passing an unshifted copy of the argument array.
Replace unnecessary cat ... | with ...
Update version function to match copyright data at top of file.
---
contrib/bacman.sh.in | 85 ++--
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/contrib/bacman.sh.in b/contrib/bacman.sh.in
index 5435e40..bcc0e73 100644
--- a/contrib/bacman.sh.in
+++ b/contrib/bacman.sh.in
@@ -27,6 +27,9 @@ shopt -s nullglob
declare -r myname='bacman'
declare -r myver='@PACKAGE_VERSION@'
USE_COLOR='y'
+INCLUDE_PACNEW='n'
+# Required for fakeroot because options are shifted off the array.
+ARGS=($@)
m4_include(../scripts/library/output_format.sh)
@@ -35,19 +38,27 @@ m4_include(../scripts/library/output_format.sh)
#
usage() {
echo This program recreates a package using pacman's db and system
files
- echo Usage: $myname [--nocolor] installed package name
+ echo Usage: $myname [--nocolor] [--pacnew] installed package name
echo Example: $myname kernel26
}
version() {
printf %s %s\n $myname $myver
echo 'Copyright (C) 2008 locci carlocci_at_gmail_dot_com'
+ echo 'Copyright (C) 2008-2013 Pacman Development Team
pacman-dev@archlinux.org'
}
-if [[ $1 == --nocolor ]]; then
- USE_COLOR='n'
- shift
-fi
+while [[ ! -z $1 ]]; do
+ if [[ $1 == --nocolor ]]; then
+ USE_COLOR='n'
+ shift
+ elif [[ $1 == --pacnew ]]; then
+ INCLUDE_PACNEW='y'
+ shift
+ else
+ break
+ fi
+done
m4_include(../scripts/library/term_colors.sh)
@@ -71,7 +82,7 @@ if (( EUID )); then
if [[ -f /usr/bin/fakeroot ]]; then
msg Entering fakeroot environment
export INFAKEROOT=1
- /usr/bin/fakeroot -u -- $0 $@
+ /usr/bin/fakeroot -u -- $0 ${ARGS[@]}
exit $?
else
warning installing fakeroot or running $myname as root is
required to
@@ -140,7 +151,6 @@ cd $work_dir || exit 1
#
msg2 Copying package files...
-cat $pkg_dir/files |
while read i; do
if [[ -z $i ]]; then
continue
@@ -153,24 +163,55 @@ while read i; do
case $current in
%FILES%)
- ret=0
- if [[ -e /$i ]]; then
- bsdtar -cnf - /$i 2 /dev/null | bsdtar -xpf -
-
- # Workaround to bsdtar not reporting a missing
file as an error
- if ! [[ -e $work_dir/$i || -L $work_dir/$i ]];
then
- error unable to add /$i to the package
- plainIf your user does not
have permssion to read this file then
- plainyou will need to run
$myname as root
- rm -rf $work_dir
- exit 1
+ local_file=/$i
+ package_file=$work_dir/$i
+
+ if [[ ! -e $local_file ]]; then
+ warning package file $local_file is missing
+continue
+ fi
+ ;;
+
+ %BACKUP%)
+ # Get the MD5 checksum.
+ original_md5=${i##*$'\t'}
+ # Strip the md5sum after the tab.
+ i=${i%%$'\t'*}
+ local_file=/$i.pacnew
+ package_file=$work_dir/$i
+
+ # Include unmodified .pacnew files.
+ local_md5=$(md5sum $local_file | cut -d' ' -f1)
+ if [[ $INCLUDE_PACNEW == 'n' ]] \
+ || [[ ! -e $local_file ]] \
+ || [[ $local_md5 != $original_md5 ]]; then
+ # Warn about modified files.
+ local_md5=$(md5sum /$i | cut -d' ' -f1)
+ if [[ $local_md5 != $original_md5 ]]; then
+ warning package file /$i has been
modified
fi
- else
- warning package file /$i is missing
+ # Let the normal file be included in the
%FILES% list.
+ continue
fi
;;
+
+
[pacman-dev] Destination directory for VCS sources
Hi, Is there currently any built-in way in makepkg to save VCS source checkouts to a custom directory separate from static source archives? Regards, Xyne
[pacman-dev] XferCommand substitutions and quoting
Hi, The commented XferCommands in the default pacman.conf lack proper quoting. Would you please add single quotes around the place holders %u and %o? Thanks. Regards, Xyne
[pacman-dev] [RFC] support for URL query strings and fragments
Hi, pacman/libalpm currently only supports bare server URIs of the form scheme name : hierarchical part whereas a full URI is scheme name : hierarchical part [ ? query ] [ # fragment ] Support for query strings would allow for more flexible server configurations using dynamic content. For the sake of a concrete example, I'm in the middle of rewriting Pacserve and I could really use ?repo=$repoarch=$arch to keep all packages in one apparent server directory while still being able to correctly redirect to external mirrors. Redirection requires both values to determine and interpolate the server URL before returning it to Pacman with a 307. At first I thought this would be relatively easy to do. I took a quick look at the code but I didn't find a common function to affix the file name to the URL (although I did see sanitize_url in db.c). I see two ways of doing this: 1) Support a $file variable in the URL. If the URL doesn't contain the variable, add the file name to the end as usual. 2) Remove the query and fragment, treat the URL as usual, then restore the query and fragment. The first would allow for file names in query strings (e.g. ?file=$file). It could be used for a build server, for example. Of course, you can extract the file name from the request path but that requires hacking the server code or using something like mod_rewrite to mangle URLS. Having the file name sent in a get variable is much more convenient for server-side programming. In either case, it should be enough to have a single, central function that accepts the template URL and the filename (pkg or db) and returns the full URL. The sanitize_url function would also need to handle query strings and fragments. Would there be any objection to this if a patch were submitted?
Re: [pacman-dev] [RFC] support for URL query strings and fragments
On 2013-05-10 18:02 +0300 Mohammad_Alsaleh wrote: The first would allow for file names in query strings (e.g. ?file=$file). It could be used for a build server, for example. Of course, you can extract the file name from the request path but that requires hacking the server code or using something like mod_rewrite to mangle URLS. Having the file name sent in a get variable is much more convenient for server-side programming. Maybe I didn't understand your problem. But wouldn't using the Content-Disposition header solve it? That is unrelated. Going back to the Pacserve example. the server runs on localhost. When a package is requested via an HTTP GET request, it checks the local cache for the package and returns it if it is there. If not, it queries other Pacserves on the LAN and sends a simple 303 response to redirect to a Pacserve server that has the package, if there is one. Because Pacserve only serves packages (and not databases), there is no need to have different directories for different repos and architectures. The architecture is contained in the package name and the repo is unimportant. The same reasons permit the official servers to keep all of their packages in the pool directories without any confusion. The problem arises when no local Pacserve servers have the package and Pacserve needs to redirect to an external mirror. It then needs to know which repo and which architecture the package is for so that it can select the correct URL from pacman.conf and replace the $repo and $arch variables in the URL before returning it to the client with the package name appended. Currently this information must be gathered by creating paths such as /core/os/i686 /core/os/x86_64 /extra/os/i686 /extra/os/x86_64 ... on the server. Even if you have access to the server software and can tweak the configuration or settings for path rewriting (e.g. with Apache's mod_rewrite, directly or via .htaccess), it's still a pain and it's silly if all you need are the repo and arch values. It should be possible to pass those values via GET parameters in such a way that pacman can convert: Server = http://example.com/pkgs/?repo=$repoarch=$arch to http://example.com/pkgs/foo-1.3-4-x86_64.pkg.tar.xz?repo=bararch=x86_64 Pacman blindly interpolates $repo and $arch, so that works (although it really should percent-encode them to be sure), but does not understand the query string and fragment parts of the URI, so it can't append the name to the path. For now I have worked around it with Server = http://localhost:15678/pkg/?repo=$repoarch=$archfile= but that is a kludge that requires additional server processing and it still generates malformed URLs because it will be converted to ...file/foo The forward slash should be percent encoded and there is no way to get Pacman to omit the slash, so even if it works in some cases, it is technically wrong. Obviously I have started this discussion because I could really use this for pacserve, but it would also be very useful for scripting package servers. You could send all the desired information to the server via GET parameters (repo, arch, package) and have the server locate or build the package. With this, everything is controlled entirely by a single script on the server. Without it, the path has to be mangled, which requires access to the server software or particular settings. To preempt one possible argument, Arch might not officially support such URIs, but pacman aims to be distro-agnostic. Besides, modularizing code and making it more robust is a good thing. I hope that clears up the idea. I'm tired and likely rambling, so I'll shut up now.
Re: [pacman-dev] pacman-4.2 plans?
Allan McRae wrote: On 14/04/13 09:52, Anatol Pomozov wrote: What happens if the network connection is dropped while packages are still downloading after package installation has started? In this case only those packages that are already downloaded will be installed. And because installation respects dependency order then partial installation will not brick the system, no? Sure it can... e.g. an soname bump in ncurses. ncurses gets updated but nothing else, bash is dead. Allan You could check for isolated subgraphs of the dependency graph in the downloaded package set and install those together as other packages are still being downloaded. If you don't want to parallelize downloads yet then you can order the download queue by such subsets. Regards, Xyne
Re: [pacman-dev] pacman-4.2 plans?
Allan McRae wrote: We need all packages downloaded to perform conflict checking. Installing in parallel would be difficult as we need to maintain dependency ordering. Aside from that, wouldn't parallel disk IO be slower due to the write head having to jump back and forth more often? What do you plan to parallelize? Compression and decompression of DBs and packages? Dependency, provider and other metadata resolution?
Re: [pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored
Xyne wrote: This may break simple scripts that naively parse the output (updaters, notifiers, downloaders, ...). While that is not officially supported there is really no reason to change expected behavior for this. I think a better approach would be to omit ignored packages unless they are explicitly included on the command line. Otherwise perhaps you could use a special argument to '--ignore' (or a custom option) to stop ignoring packages for a given operation (e.g. --ignore -). Both cases remain backwards compatible with past behavior and avoid surprises. Regards, Xyne Just to give a concrete example of how this applies, let's say that the user has ignored foo. Running pacman -Sp group where foo is a member of group should not include foo in the output. It would also apply when printing groups that overlap with ignored groups. Allan McRae wrote: I just realised that pacman -Sp --ignore glibc glibc makes little sense, so just -Sup case then. In that case it doesn't, in others it does. Explicit --ignore options should override command-line arguments. For example, pacman -Sp --ignore foo $(pacman -Slq bar-repo) where foo is a member of [bar-repo]. Of course you can run the repo list through grep or some other filter, but it is logical to expect an --ignore option to force pacman to ignore a package and I think it would be consistent behavior.
Re: [pacman-dev] Tar backend for local db
Allan McRae wrote: This would also give another use for pacman -D - an option could be added to recreate the local db tarball - in case it became corrupt or the files were manually edited. That would be an essential function as manual edits are quite common. The thing you are missing is EVERYTHING in pacman apart from the local db is in tar format. The packages are tarballs, the sync dbs are tarballs. We use a very good library for reading from tarballs without extracting them. We have a really shiny hammer and and a lot of nails, so we may as well just use our shiny hammer on everything. It makes sense that packages are tar archives. A package is a fixed set of files arranged in a hierarchy. That's what tar was meant to store. Databases on the other hand are different. You can argue it any which way you want, but it's obvious that the multiple files/tarred archive approach was a lazy shortcut to avoid a proper solution that would have required time to implement, test and debug. At first Judd or whoever presumably just wanted to get it working, and subsequent improvements were made on what was already there. Now it's grandfathered in with all the emotional attachment and a proud member of the good enough club, but that does not mean that it's optimal. SQLite makes sense for both sync and local databases. I expect it would be faster and more versatile. The data would be stored in a common data format and not require custom files and parsers. It would facilitate the creation of third-party tools. Is this a big deal? No. As stated, the current solution is already good enough. Further improvements will be welcomed, but there must come a point where you ask yourself if complicating an existing suboptimal solution to shave off a few seconds is really better than implementing a proper solution to the problem. Eventually you will want a proper solution, and then the current effort will be at least partially wasted. All that aside, +1 for tarring the local db to improve speed, as long as the local files remain easily accessible for manual editing. Regards, Xyne
Re: [pacman-dev] The great VCS packages overhaul of 2015
Dan McGee wrote: I don't like the @@ and :: syntax. Maybe git://remotename//http://projects.archlinux.org/git/pacman.git;? That way we can simply look for git:// and also easily figure out if there is a remote name or not. // should also be a safe delimiter because in the URL it would be collapsed to / anyway. Heck no, minus -1000. We are **not** reinventing a URL syntax. This is confusing, misleading, and awful. Look at this: git://remotename//git://projects.archlinux.org/pacman.git I don't even know what remotename is (but if that can contain a '/', my eyes will really bleed). The double URL specifier (using the same protocol twice!!) is likely not allowable or recommended by http://tools.ietf.org/html/rfc3986. If you are trying to stick with URI/URL format, I'd much rather see git+http:// in this case, which is a lot like the 'svn+ssh://' protocol you can use, etc. And then use fragment identifiers perhaps (RFC 3986, 3.5, '#branchname') to identify the branch name. Please do this, and modularize the handlers in such a way that users can create new ones without hacking/patching the makepkg source. For example, create a directory similar to /etc/profile.d with files that get sourced by makepkg. Files in this directory could contain functions with scheme prefixes and common names, e.g. for git+http you might have git_http_download and for svn+ssh you would then have svn_ssh_download. The *_download function would be responsible for handling cloning and updating as necessary. It could accept the URL minus the fragments as first argument, the target/build directory as second argument, and then the fragments as additional arguments. Obviously that's just an example off the top of my head and you will have better ideas of how to implement it (e.g. maybe leave parsing to the function). The real purpose it to effectively create a VCS plugin system. Aside from providing users with flexibility, it would also crowdsource the creation of new VCS handlers. They could even be provided as optdepends. For versions, the *_download function could return one or there could be a special *_version function, but mixed sources may be a problem in that case. You could simply make it a guideline/requirement that the version be the date of the last VCS release or source modification. The version of the package would then be the version of the last release/modification of any source. That should simplify version handling across different VCS. I don't recommend using release tags as versions because there will be no way to compare them meaningfully in many (most?) cases. Just some thoughts. Regards, Xyne
Re: [pacman-dev] pyalpm 0.4
Allan McRae wrote: On 14/04/11 08:59, Thomas Bächler wrote: Am 14.04.2011 00:27, schrieb Dan McGee: On Wed, Apr 13, 2011 at 5:15 PM, Thomas Bächlertho...@archlinux.org wrote: Am 13.04.2011 23:50, schrieb Rémy Oudompheng: Pyalpm can be found at ftp://ftp.archlinux.org/other/pyalpm/pyalpm-0.4.tar.gz (when FTP site will be synchronized) and is meant to be compilable on other platforms than Archlinux, possibly with modifications to CPPFLAGS. Do you have a git tree for it? This should definitely on projects.archlinux.org. You mean like http://projects.archlinux.org/users/remy/pyalpm.git/ ? Heh :) Maybe we should still move it out of /users. In fact, I would not mind seeing a semi official alpm-bindings project. We have python, lua, and the start of go bindings that I can remember of the top of my head. Allan I have Haskell bindings... or at least I did for 3.5. When I get some time I intend to update them, test them extensively, and release them... hopefully in that order. :P Regards, Xyne
Re: [pacman-dev] [pyalpm] released version 0.2
Rémy Oudompheng wrote: Hello, pyalpm version 0.2 is available at ftp://ftp.archlinux.org/other/pyalpm/pyalpm-0.2.tar.gz There is also a PKGBUILD on AUR. I have not really wrapped more libalpm functions, but I have begun writing a clone of pacman in Python. The goal is multiple: * have Python modules giving access to pacman functionalities which are not strictly in libalpm (like configuration via pacman.conf) * have an easy way to test the bindings more extensively * provide material allowing to hack quickly a pacman variant * see how the use of another language affects pacman's code * have fun For the moment, it is in a very early stage and only gives access to simple database lookup functions. The script is called pycman and supports options -Q[ilq], -S[iglq], -T. pycman/pyalpm works with Python 3.2 (needed for argparse module) and libalpm from pacman 3.5 (the current targeted API). -- Rémy. Hi, I'm following this with interest. It should be very useful for both full applications and quick scripts, and I'm sure that I'll have some fun with it when I have the time. You might find the Reflector module (Python 3.2) useful: http://xyne.archlinux.ca/projects/reflector/ If no one else does (and maybe even if they do), I might eventually write an AUR module to interaction with the RPC interface. That should complement pyalpm nicely. Is this intended to become an official project, or just a fun personal project? Regards, Xyne
[pacman-dev] pacman -Rd still checks deps
Hi, With pacman 3.5.1 from [testing] I get this: pacman -Rd mimeo checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: obfilebrowser: requires mimeo=2011.03.12 (tested with --nodeps too, just in case) I couldn't find anything about this on the bugtracker but I may be looking in the wrong place. If this is an unknown bug, please tell me where I should report it, if not here. Regards, Xyne
Re: [pacman-dev] 3.5.0 release planning
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?
Re: [pacman-dev] [PATCH] Remove need to explicitly register the local DB
Allan McRae wrote: The lazy initialisation means that nothing is actually loaded when registering the local database. The local database is only read in as needed and only the parts that are needed are read in. In fact, all that is done registering the local database is creating a pmdb_t srtuct and assigning the local database operation struct to it. That is the little to no fallout if you do not use the local database. Allan Thanks for the clarification. 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. Don't worry though, I'll leave it there as I have no intention of pestering you about something that is effectively irrelevant. I just see it as lazy design in a bad way. Regards, Xyne
Re: [pacman-dev] [PATCH] Remove need to explicitly register the local DB
Dan McGee wrote: There is rarely a reason to ever not set up the local DB when getting a libalpm handle, so just do it automatically at this time. It is still a lazy initialization anyway, so there should be little to no fallout from doing it this way. I'm concerned about the uncertainty of little to no fallout. What exactly does the lazy initialization do? Does it in any way rely on the presence of a local database? I ask because I have a tool in mind that will use ALPM to query the sync database, most likely in the absence of a local database. It also strikes me as bad design to hard-code something that is not necessary for all operations, especially for a library that is at least intended for use beyond Pacman. Wouldn't it make more sense to create a separate routine to automatically set up the local DB when getting a libalpm handle? Applications that need the local DB could just use that instead wherever they acquire the handle.
[pacman-dev] Alternative dependencies.
Hi,
Would it be possible to implement support for alternative dependencies, e.g. a
package that could use either wget or curl to handle downloads?
I'm not asking for this to be implemented. I'm just asking whether there are
any technical limitations to such an approach.
I know that provides can be used to do this, e.g. openjdk6 and jre both
provide java-runtime to satisfy that dependency in other packages. The approach
is limited though. Using the example above, we couldn't simply add
provides=('download-client') to both curl and wget because they are not
interchangeable.
The basic usage case is when an application is capable of detecting any one of
a number of different external apps that it can use to satisfy a given
dependency. There is currently no way to depend on at least one of those.
I can imagine a very simple syntax for this too, e.g. depends=('curl ||
wget') so the question is whether the dependency-handling mechanism could be
adapted to check for alternatives. If none are found, it could probably use the
upcoming provides selection dialogue to allow the user to choose the desired
dependency.
So, would that be possible?
Also, would that be acceptable?
Again, I'm not asking anyone to do this. I'm just inquiring about the
possibility.
Regards,
Xyne
Re: [pacman-dev] Alternative dependencies.
Xyne wrote: Well, a concrete example would be pbget, which checks for both curl and wget, although that's not what led me to ask. Um, apparently it doesn't. Something that I've written does though, or at least used to.
Re: [pacman-dev] [PATCH] Add script to update pacman database format
Allan McRae wrote: The pacman-db-upgrade script was added to detect old pacman database formats and upgrade them. Currently performs the merging of depends files into desc files in the local database. When is this expected to be released? I'll need to update perl-xyne-arch to handle this and it would be useful if I could insert a versioned dependency to prevent any breakage during the transition period. Am I correct in believing that the file format remains the same and that the merger is a simple insertion of the depends file into the desc file?
Re: [pacman-dev] [PATCH] Add script to update pacman database format
Allan McRae wrote: On 09/12/10 00:00, Xyne wrote: Allan McRae wrote: The pacman-db-upgrade script was added to detect old pacman database formats and upgrade them. Currently performs the merging of depends files into desc files in the local database. When is this expected to be released? I'll need to update perl-xyne-arch to handle this and it would be useful if I could insert a versioned dependency to prevent any breakage during the transition period. It has not hit the master git branch yet, but I would expect it to hit in the next major pacman release (3.5?) which is probably months away. Am I correct in believing that the file format remains the same and that the merger is a simple insertion of the depends file into the desc file? Correct - for the local db. The sync db format will not change (transition period is needed) but note that the sync dbs will not be extracted from their tarball any more. Allan Thanks for the warning.
[pacman-dev] Versioned packages on the command line.
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 Regards, Xyne
Re: [pacman-dev] Versioned packages on the command line.
Xavier Chantry wrote: 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 ? Sorry, I had only tried -Si foo=x.y. Thanks for being pre-emptively awesome. :)
Re: [pacman-dev] [PATCH] Add interactive provider selection
On 2010-10-19 21:10 +0200 (42:2) 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). 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. Is the install size shown after each package when ShowSize is enabled? That would be useful when deciding which package to install. It would be even more useful to know the cumulative size, i.e. the sum of install sizes of that package and its own dependencies. I think that would be the deciding factor in most cases. Regards, Xyne
Re: [pacman-dev] Groups. Again.
Xavier wrote: Hi list Jakob and I have been going back and forth about where groups handlings should be, in backend or frontend, and how alpm interface should look like. It turns out Jakob has several arguments for the group backend solution, and he spent quite some time working on it, improving and fixing things. This solution fixes several flaws that pacman currently has without drastically changing the code. There are just two disappointing aspects that Jakob covered below in bad news. Also there are still some points I would like to see improved, but more aesthetic than real issues, so low priority. I was going to cover them here, but this will just confuse things and would deserve its own topic/discussion. I'm re-proposing that we scrap groups entirely in favor of metapackages. (I think I send a message to this list about this over a year ago.) A metapackage would consist of an empty package (i.e. no installable files other than pacman metadata). The package would list the members of the metapackage as optdepends. For this to be useful, the following would be needed: * optdepends dialogue: this would be (almost?) identical to the current group dialogue... the user could then either select all members of the metapackage or just the ones he wants, exactly as groups currently work * user-selected optdepends would need to be handled by pacman: an easy way to do this is to add an extra directory to the database alongside local and sync to store data about user-selected optdepends (soft deps, as opposed to hard deps specified by depends). For the sake of example, let's call this directory custom. When a user installs an optdepend specifically for package foo (i.e. makes it a soft dep of foo), the directory custom/foo would be created in the database. Inside that directory, a file named depends would be created. This file would be analogous to the depends file in the local and sync directories. custom/foo/depends would contain a section named %DEPENDS% and in that section it would list all soft deps installed by the user for foo. When pacman needs to check the dependencies of any package, it loads the depends file in sync or local, depending on the operation. At this point, pacman has an internal list of the package's dependencies. It should then check for the existence of custom/$pkgname/depends. If that file exists, it should be loaded and all packages listed in that file's %DEPENDS% section (the optdepends specified by the user) should be added to the aforementioned internal list of dependencies. At that point, all optdeps specified by the user will be treated as though there were deps of the package and pacman can manage them without any further changes. The overhead of testing for the existence of a file should be negligible. By keeping this in a separate directory in the database (custom in this example), the local and sync databases are unaffected, i.e. no files in either of the existing databases would need to be changed, plus custom could be extended later if necessary (e.g. to allow users to associate files with packages, e.g. config files). Other benefits would be automatic upgrades... currently a user has to manually check if a new package is added to a group and anyone can place their own packages in any group. With metapackages as specified above, only the maintainer of the metapackage can control which packages are included in it, and when the maintainer adds a new package to the group, the new optdep hook would inform the user (and maybe even trigger the selection dialog). * The optdep dialogue should be accessible for managing optdeps locally, i.e. when not installing, e.g. pacman -Q --optdeps foo. This should also let the user. * An --asoptdepsfor (or --assoftdepsfor) option should be added to make packages soft deps of another package, e.g. pacman --assoftdepsfor foo bar baz would make bar and baz soft deps of foo. * An old optdep hook could inform the user when an optdep installed as a soft dep has been removed from a package, e.g. foo used to list bar as an optdep so the user installed bar as a soft dep, but now foo has dropped bar as an optdep, so a message is display upon upgrade. * Files and dirs in custom should be removed when they are empty. Advantages: * groups can be completely replaced with something that follows as a natural consequence of pacman's standard behavior with all benefits that it brings * soft deps would not need to be limited to optdepends, thus users could easily manage their own custom dependencies I would really like to hear some thoughts about this approach from the devs. Regards, Xyne
Re: [pacman-dev] [PATCH] 2nd attempt at: Fixed untranslated entries in Swedish translation
On 2010-09-03 00:09 +0200 (35:5) Tobias Eriksson wrote: Hi list! I botched the last patch, but now it should be correct and applies cleanly. I looked over the Swedish translation of pacman, and wrote translations for the untranslated entries. There are 401 translated entries, 41 fuzzy and 0 untranslated. I'll get to fixing the fuzzy ones when I get the time. Hi, A few notes and suggestions: * You've used packet in some places instead of paket. * The mirror '%s' would be the address of the server, so Förrådet '%s' sounds strange to me. Maybe Webbadressen '%s' would be a more natural translation? * är definerad - har definerats? * är i konflikt - är oförenliga? * Installerar %s paketgrupp med %s -U... - Installerar paketgruppen %s med %s -U... (both word order and use of definite form) * efterfrågade paket %s - efterfrågade paketet %s? (and paket x - paketet x elsewhere in that case) Please don't take this as criticism. I know that it can be difficult to find a natural translation, especially with limited context. Adding to the difficulty, English technical terminology is readily used and understood without translation and thus sometimes there is no natural translation. It's just a bit sad that most of it ends up looking like word-for-word online translations or lazy svengelska (I'm speaking generally here, not about your patch). Before anyone tells me to just do it myself: a) I think I submitted translations before but they were ignored (not sure though). b) I don't use them. c) Having a single person translate will only get you a translation full of that person's linguistic idiosyncrasies... I am sure that I have many.
Re: [pacman-dev] Explicit (opt)deps for makepkg.
Tobias Eriksson tob...@tobier.se wrote: Please add file to that list and please don't tell me to submit a patch or file a bug report for something that trivial. There's enough pointless bureaucracy in the world as is. This is how open source development is done. If you want something fixed then either submit a bug report or fix problem yourself with a patch. If you don't like it... too bad for you. Whoever needs to see this has or will see it. There is no reason to jump through extra hoops. It's like someone telling you that you left your headlights on, and you respond with send me an email about it. In this case, asking for a patch that adds a single word to a comment is silly, and I would still have to submit the patch to someone for it to be applied, which would actually require more work than simply changing that line in the first place. Chanting the submit a patch mantra without regard for context seems to be a consequence of long-term development and concomitant apathy. If you don't want to fix it, then don't.
[pacman-dev] Explicit (opt)deps for makepkg.
Hi, I think the pacman package should explicitly list makepkg's optional dependencies, instead of simply assuming the presence of base and base-devel. Using a minimal 32-bit chroot, the only way to keep it minimal is to try to run makepkg and then track down each dependency-related error one by one until it completes. There is no reason to install a huge group when only a few of those packages are actually required (e.g. file from base) and doing so simply leads to unnecessary downloads and chroot pollution. The shotgun approach to package installation for makepkg has always struck me as unminimalistic. I understand that the omission of explicit dependencies is seen as simple by some, but that's probably how the huge DE devs view their dep chains too. Maybe base-devel could encompass all hard dependencies of makepkg and nothing more, and then be listed as an optdep for makepkg. Packages that require anything beyond that should list the additional (build) deps explicitly. Thoughts? Regards, Xyne
Re: [pacman-dev] Explicit (opt)deps for makepkg.
Allan McRae wrote: On 19/07/10 06:24, Xyne wrote: Hi, I think the pacman package should explicitly list makepkg's optional dependencies, instead of simply assuming the presence of base and base-devel. You have reached the list for the development of pacman. For discussion of distribution specific issues on packaging, you should use the facilities provided by your distribution (e.g. mailing lists/forums/bug tracker). Suddenly I feel as if I'm in a Monty Python sketch, but I'll play along. See you at the next teller window. Using a minimal 32-bit chroot, the only way to keep it minimal is to try to run makepkg and then track down each dependency-related error one by one until it completes. The dependencies for makepkg are given at the top of makepkg itself. If any are missing, provide a patch or file a bug report. # makepkg uses quite a few external programs during its execution. You # need to have at least the following installed for makepkg to function: # bsdtar (libarchive), bzip2, coreutils, fakeroot, find (findutils), # gettext, grep, gzip, openssl, sed, tput (ncurses), xz == Extracting Sources... /usr/bin/makepkg: line 663: file: command not found == Entering fakeroot environment... /usr/bin/makepkg: line 1749: file: command not found Please add file to that list and please don't tell me to submit a patch or file a bug report for something that trivial. There's enough pointless bureaucracy in the world as is.
Re: [pacman-dev] .so provides/depends patches review
Hi, Sorry this has taken me a while... so long in fact that I do not have the original email stored anymore to reply to. But here goes my comments on the patches for soname provides/depends: http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010431.html My comments are currently only on functionality. I'll get to code after that is fully sorted. Firstly, it works well and does as advertised. So no issues there... However: 1) If I put a bad soname provides in the array (e.g. provides=readline.so) it just silently ignores it. No error and nothing put in the .PKGINFO. There needs to be an error (or at minimum a warning). The same goes for depends (although these are mostly caught by the initial dependency checking in makepkg). 2) Building readline on i686 with provides=libreadline.so, in the .PKGINFO I get: provides = libreadline.so=6-elf32_i386 My concern about that is that the library is not i386 but is i686. I may be prepared to accept that though as I guess x86 is x86 really... But what additional information is the elf32 providing? I could perhaps understand the operating system from the host triplet. If anything, my preferences are: libreadline.so=6-i686_linux (best) libreadline.so=6-i686 / libreadline.so=6-i386_linux libreadline.so=6-i386 (worst) Allan Would it (make sense|be possible) to generalize this beyond .so files so that it can accommodate other uses in the future? The first thing that comes to mind is that this might be useful for packages which provide modules for interpreted languages as well (e.g. CPAN distributions for Perl) but there are almost certainly other valid uses. As I've understood it, this is really just a way to provide finer dependency control and it seems that it should not be limited to particular file types. Sorry if this is already the intention but from what I've read of the discussion it seems that only compiled (C and C++) shared libraries have been considered. I've admittedly only followed the discussion loosely and have not read through the code itself so sorry again if I've misunderstood something. Xyne
Re: [pacman-dev] Matching split packages to PKGBUILDs
There is no naming convention and there shouldn't be any. Just read the pkgbase var from the repo or BASE from the package itself to determine the base PKGBUILD. Thanks, I was unaware of that.
Re: [pacman-dev] Parsing variables in PKGBUILD packaging functions.
Well, did you read the post before yours on this list? It shows a
fairly simplistic approach bash that works quite well and is what I will
use for the makepkg test suite. It does require sourcing the PKGBUILD
though, so should not be used on untrusted PKGBUILDs...
Then there is the parched scripts being written for AUR2 that use
yacc/lexx + python (from memory...) - see recent posts by Sebastian
Nowicki on this list.
Allan
I came up with my own (possibly clever?) solution.
* check the PKGBUILD with /bin/bash -n to make sure it's well formatted
* wrap the entire PKGBUILD in a function and source it (step one
guarantees that the code is trapped within the wrapping function and
thus not actually executed)
* capture the output of set which spits out the code in canonical
format, i.e. normalized whitespace etc which makes it easier to parse
with regexes
* walk the code, finding variables as you go and interpolate what needs
to be interpolated by keeping track of local variables within each
function
Obviously it will fail for some things but so far it seems to work with
the PKGBUILDs that I've tried.
You can find my parser in the latest version of perl-xyne-arch on my
site (major code rewrite so it needs to wait before it hits community).
I've attached a script which will parse PKGBUILDs and spit out a
modifed JSON format of the data (change the comments to get real JSON).
I've also attached the output from parsing kernel26, which is split.
So far I've also added string substitutions and will add other variable
tricks later. I have no idea how far along any of the other methods
are, such as yacc/lexx + python approach, or if this is even
embarassingly simplistic, but it works for bauerbill (see site/forum)
for now.
Xyne
kernel26
Description: Binary data
#!/usr/bin/perl
use strict;
use warnings;
use Xyne::Arch::PKGBUILD qw/parse_pkgbuild/;
use Xyne::Common::Functions qw/str/;
use Xyne::Common::JSON qw/obj_to_json/;
foreach my $pkgbuild (@ARGV)
{
foreach my $o (parse_pkgbuild($pkgbuild))
{
print str($o,1);
#print obj_to_json($o,1);
print \n\n;
}
}
#print obj_to_json(parse_pkgbuild(@ARGV),1);
[pacman-dev] Parsing variables in PKGBUILD packaging functions.
Hi, Is there any way to _unequivocally_ parse PKGBUILD variables within a package function, e.g. depends, without executing the entire code block? Please tell me that you don't actually need to build the package(s) to get all of the variables. Thanks, Xyne *holds breath and hopes*
Re: [pacman-dev] IgnorePkg + IgnoreGroup +-Qu
Hi, I just wanted to ask if the output of pacman -Qu is meant to contain ignored packages and groups or if that's a bug. I don't believe it did so previously. Regards, Xyne I filed a bug[1] about this previously. The -Su --print option planned for 3.4 will give us more or less equivalent output as pacman 3.2. Yeah, that's what I thought too, but I suspect that the inclusion of ignored packages is one of those we, uh, MEANT to do that, cuz, you know, uh, we were planning to improve -Su --print all along. :P
Re: [pacman-dev] [PATCH] '-Spp and -Supp' options were added to generate uri list without the downloaded package uris
Here are some output of the patch just sent to the ML. $ pacman -Sp --print-format %r/%n-%v : %l [%s] kdelibs extra/qt-4.5.2-6 : http://mir1.archlinuxfr.org/archlinux/extra/os/i686/qt-4.5.2-6-i686.pkg.tar.gz [28914122] extra/ilmbase-1.0.1-1 : http://mir1.archlinuxfr.org/archlinux/extra/os/i686/ilmbase-1.0.1-1-i686.pkg.tar.gz [0] extra/openexr-1.6.1-1 : http://mir1.archlinuxfr.org/archlinux/extra/os/i686/openexr-1.6.1-1-i686.pkg.tar.gz [0] $ pacman -Up --print-format %r/%n-%v : %l [%s] /var/cache/pacman/pkg/bash-4.0.028-1-i686.pkg.tar.gz local/bash-4.0.028-1 : /var/cache/pacman/pkg/bash-4.0.028-1-i686.pkg.tar.gz [0,93] $ pacman -Sp --print-format %r/%n-%v : %l [%s] bash core/bash-4.0.028-1 : http://mir1.archlinuxfr.org/archlinux/core/os/i686/bash-4.0.028-1-i686.pkg.tar.gz [0,00] $ pacman -Rdp --print-format %r/%n-%v : %l [%s] bash local/bash-4.0.028-1 : bash-4.0.028-1 [2,60] Nice work. Thank you for implementing this.
Re: [pacman-dev] [PATCH] '-Spp and -Supp' options were added to generate uri list without the downloaded package uris
Instead of adding several options, wouldn't it be possible to let -p accept a string argument with formatting information similar to the way the date command works. This would be extensible in the future and could include the following interpretted sequences (among others) %u - url %n - pkgname %v - pkgver-pkgrel %s - size %r - repo I think the repo would be very useful as well. btw the copy/paste were my previous --print patch which did not have the --print-format option. my new patch has %u %n %v, and adding %s and %r will be easy as well. one problem is that url and repo are only available for the -S operation. or maybe url could just be replaced by the filename for -U and -R. and repo by 'local' I think using local for %r is a good idea. As for %u, maybe it should be changed to % l for location. It could return the full path to the package archive when using -U. It's relatively useless for -R but I agree that it should return something for the sake of uniformity. Maybe the full path to the local database entry would be useful, e.g. /var/lib/pacman/local/foo-3.5-1 On a tangent, thinking about the printed output of -U, Is there any reason that it doesn't resolve dependencies?
Re: [pacman-dev] [PATCH] '-Spp and -Supp' options were added to generate uri list without the downloaded package uris
Instead of adding several options, wouldn't it be possible to let -p accept a string argument with formatting information similar to the way the date command works. This would be extensible in the future and could include the following interpretted sequences (among others) %u - url %n - pkgname %v - pkgver-pkgrel %s - size %r - repo I think the repo would be very useful as well.
Re: [pacman-dev] [PATCH] '-Spp and -Supp' options were added to generate uri list without the downloaded package uris
--print-pkg and --print-uris looks good to me but would you keep your new feature on top of these two options : --print-pkg and --print-uris only show non-download packages --print-pkg --print-pkg and --print-uris --print-uris show all ? an alternative : what if we added the download size when ShowSize is used? pacman -Sp fontconfig ftp://ftp.archlinux.org/extra/os/i686/fontconfig-2.4.2-1.pkg.tar.gz [1234] pacman -Spq fontconfig ftp://ftp.archlinux.org/extra/os/i686/fontconfig-2.4.2-1.pkg.tar.gz pacman -Sp ... | grep -v \[0\] | cut -d' ' -f1 ftp://ftp.archlinux.org/extra/os/i686/fontconfig-2.4.2-1.pkg.tar.gz I'm trying to follow this right now but I haven't understood what non-download packages vs all means. Can someone please refer me to the discussion about this? I tried grepping the list but didn't find anything. Instead of adding several options, wouldn't it be possible to let -p accept a string argument with formatting information similar to the way the date command works. This would be extensible in the future and could include the following interpretted sequences (among others) %u - url %n - pkgname %v - pkgver-pkgrel %s - size I don't know how difficult it would be to code but that seems the most elegant to me, rather than hardcoding the output format and having to worry about extensibility and breakage in the future. This might not make sense though in terms of non-download vs all but as pointed out, -yy and -cc mean all, so -pp should too. I'm not sure how the double flag would work with accepting an argument. Maybe there should be an additional argument --print-format which accepts the string, but then we're back to extra argument silliness again (although that would enable -p to easily default to printing URLs). As far as backwards compatibility with --print-uris goes, I would suggest breaking it if a better solution is found. Holding back better design because people can't slightly modify a few simple scripts is not a valid justification imho. Xyne
Re: [pacman-dev] makepkg security
The original complaint was that when using makepkg -sic, the sudo password is cached after dependency installation and malicious sudo commands might be executed during build() as the password is cached. My opinion on this is that we should not encourage people to use sudo, Aaron suggested to move it here for further discussion. What do you think? Couldn't you just add an option to kill sudo after dependency installation? ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] add makedepends to package and database
As a rather wild aside here... what would be the downside of sticking the entire PKGBUILD in the pacman DB? How much size would that add? Wont make that much sense (as it is not easily parsable and without patches etc. quite useless) However for community/ core/ extra/ kde-unstable/ local/ testing/ it is (gzip compressed) 1,1M But you're just kidding, right? Not exactly - I'm half serious. I mean, a) it'd give us all the information needed to build the package, b) it'd allow these scripts to work without an ABS tree. I'm not saying pacman would _use_ it, I just think it'd be kinda neat. Did anyone consider the idea that I mentioned in my previous reply? A quick recap: 1) Don't change sync and local databases. 2) Add a new database, possibly named abs (/var/lib/pacman/abs) 3) Create an archive for each package that contains the files in the current abs tree: -- PKGBUILD -- local source files 4) Create an abs database archive similar to the current sync db archive that contains a file (or more) with information from the parsed PKGBUILD, e.g.: %NAME% foo %VERSION% 2.3 %DEPENDS% bar baz %MAKEDEPENDS% this that something else %SOURCES% foo-2.3.tar.gz example.patch foo.png etc 5) Distribute this abs repo on the servers alongside the other repos. The user would then sync the abs database (which would only contain small files with the PKGBUILD info, so it wouldn't take much space) and be able to download packages containing everything needed to build from source The user would have the choice of installing the abs database and would only download PKGBUILDs local source files for what they actually intend to build, unlike the current abs tree which dumps everything on the users system (wasted bandwidth, wasted space). It would also be non-Arch specific. ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] wanted: script to list uninstalled optdepends and packages that need them
I had a thought today that a script to list package that are optdepends but not installed could be quite useful... I have not written one, but thought it would be good for pacman-contrib if someone wanted to contribute. Example output: tk - optional for: ruby - for Ruby/TK python - for IDLE, pynche and modulator fakeroot - optional for: pacman - for makepkg usage as normal user So get script writing! Preferably in bash or perl (which the current scripts use). If we implemented one of your suggestion for optdepends handling, which is to display when an optdepends is installed or not, then it should be very easy to do something of this kind, just using pacman -Qi and grep :) I've attached a script to list uninstalled optdepends for installed packages as Allan requested. I didn't spend much time on it though because Xavier's comment casts doubt on its usefulness. There may be a few bugs in it such as missed packages. I can probably improve it if you think it would be useful. Some caveats for the script: It parses the output of pacman -Qi. It expects the above to be in English. It strips off the version specifications to simplify checks. It considers all packages provided by an installed package to be installed themselves. and yeah, I'm now folloing this list too missingOpts Description: Binary data ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] wanted: script to list uninstalled optdepends and packages that need them
Cool but something is slightly wrong there: libburn - optional for: brasero: alternative back-end bzip2: alternative back-end bzip2 probably does not have a libbrun backend :) Allan I don't know how that happened (haven't been able to reproduce the error here). I did find some other bugs though so maybe that one was fixed indirectly. I've attached a new version. If it still lies, send me the output of pacman -Qi. missingOpts Description: Binary data ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] wanted: script to list uninstalled optdepends and packages that need them
Is there already something that can list optdepends from the local db regardless of their install status? Example: query local db (either with pacman -Qi or search lib) pick out optdepends filter packages that have optdepends match filter output eg.: $optdepend1 = $pkg1, $pkg2, $pkg3 $optdepend2 (installed) = $pkg1, $pkg4 Xyne, please do something about this with perl =p I'd really like some power to optdepends, at least until pacman treats it nicely. I remove the if statement from the script that I posted earlier to ignore the optdep installation status. Try the attached script and let me know if it does what you want (I think it does, based on your description). For those interested, take a look at Juster's script which uses his alpm module: http://bbs.archlinux.org/viewtopic.php?pid=569921 /Xyne listOptdepends Description: Binary data ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] wanted: script to list uninstalled optdepends and packages that need them
OK great, thanks. Both can be used together now - one for missingopts and one for allopts. Anyway there are going to be a few inconsistencies, aside from the format problems, mainly those of provisions (eg. qt is provided by qtmod but qt will be stated as a missing optdepend anyway). No way around that without further complexity (match with $provides). It already matches provides ;) The scripts are identical except for a single if statement. It would be trivial to add an option to switch between them if the script is actually going to be used for something. ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
