~alpine/devel

This thread contains a patchset. You're looking at the original emails, but you may wish to use the patch review UI. Review patch
36 3

[alpine-devel] [PATCH 00/15] apk-tools UI fixes/refinements

Details
Message ID
<cover.1372361242.git.dubiousjim@gmail.com>
Sender timestamp
1372361325
DKIM signature
missing
Download raw message
Some months ago, I patched apk-tools in various ways to (in my view) improve
the UI and also to provide a logging mechanism. I've been using these in
practice on my local machine. It's about time to rebase them against the
current apk-tools git repo, and see if they can be incorporated upstream.

This set of patches has the UI tweaks. It'll take me a bit longer to
rebase/test the logging patch against the current apk-tools sourcebase.

For the most part, these UI tweaks don't introduce anything that will break
existing behavior---except in 1 place (or perhaps 1-and-a-half places), which
I'll describe below. However, I have introduced some new short/long option
flags for existing functionality, and in some places have declared the old
flags "deprecated." In the current implementation, all that deprecation amounts
to is that the usage message recommends the new flag; no warnings are output
when the old flag is in fact used.

1. One set of changes is that we move some options that are now listed in the
"generic options" usage block, but which don't in fact apply to all applets,
into the applet-specific option set for the applets that use them. This applies
to -U/--update-cache, --purge, and --clean-protected.

2. A second change we introduce is that we accept "apk mkindex" to mean what
"apk index" already means, and prefer the former. This makes its behavior more
memorable,at least for me, and stops me from wondering why functions like "apk
version -l" aren't underneath the "apk index" applet instead.


A lot of changes try to impose some more consistency on the option flags,
especially the short option flags, either with other applets or with familiar
POSIX utilities.

3. One of those sets of changes concerns the various flags for recursing
upwards or downwards in the dependency tree.

Let me frame my overview of those changes with this observation: POSIX tools
mostly use -R for recursive operations (consider chmod, chown, chgrp, ls, cp,
rm). cp also accepts -r, sometimes with equivalent behavior to -R. But not all
implementations can be relied on to treat "cp -R" and "cp -r" equivalently; and
where they diverge, it's usually the first that's wanted. (See the OS X cp.1
manpage.) rm also accepts -r, and can be relied on to treat "rm -R" and "rm -r"
equivalently. But the IEEE/Open Group's rm.1p manpage recommends using "rm -R",
for consistency with other utilities. The Gnu *grep utilities (which are also
the defaults on some BSD systems) also treat -R and -r equivalently. As it
happens, BusyBox *grep only honors -r, but I will be submitting a patch to
BusyBox upstream to also accept -R, as the Gnu versions do.

The only remaining familiar utilities to ONLY accept -r for recursive
functionality are diff and rsync. On the other hand, a whole range of utilities
use -r for other purposes (consider date, touch, ls, sort, Gnu and BusyBox sed,
xargs, vi, and so on).

So the strongest existing pattern here seems to be to use "-R" to mean
"recurse".

But what does a recursive operation in a dependency tree amount to? We could
mean "also operate on the specified package's dependencies." Let's use
--depends as the long-form name of that option. (As apk-tools sometimes does;
currently it also sometimes uses --recursive here instead.) Or we could mean
"also operate on the packages that depend on the specified package." Let's use
--rdepends as the long-form name of that option. (For "reverse-depends", not
"recursive depends.") It would be confusing to have -R be the short-form option
for "--depends", and some other letter be the short-form option for
"--rdepends". So I propose we consistently use "-R" in the apk-tools namespace
to mean "--rdepends", that is, to operate recursively UPWARDS in the dependency
graph (towards packages that have more dependencies). Sometimes apk-tools
currently uses "-d" as the short-form option for the other direction
(--depends). But other times apk-tools uses -d differently. For consistency
with -R, I propose we use "-D" here instead.

So in general:

  -D/--depends means to also apply an operation to the packages that the
  specified package depends on, that is, downwards in the dependency
  graph

  -R/--rdepends means to also apply an operation to the packages that
  depend on the specified package, that is, upwards in the dependency
  graph

These patches roll out that change across the apk applets and usage messages,
while still accepting the old short and long options too, where these exist. We
just declare some of the old options as "deprecated" in the usage messages.

There's only one place where this requires us to introduce a breaking change:
currently "apk info -R" is interpreted as "apk info --depends", but these
changes will make it be interpreted in the other direction, as "apk info
--rdepends". I hope this small deviation from existing behavior is tolerable.

One awkwardness I haven't resolved is that in most cases, both the -D and -R
options are recursive: -D operates on your dependencies, and their
dependencies, and so on. However in "apk info", I think -D and -R only apply to
a single level of dependencies: only your direct dependencies, and so on. It'd
be nice if we could make this work recursively too (and perhaps had a flag to
limit the recursion to only a single level). But that isn't implemented here.


4. Another option-related change is that we now let "apk search -x" mean "apk
search -e/--exact", and prefer the former. This is consistent with the -x flag
on grep, and also steps away from the conflicting meaning of "-e" in "apk
info".



There are some other changes as well, which should be noted in the individual
commits. Here I'm just trying to give the high-level overview, not an
exhaustive description.

Here are some further ideas for changes that I DON'T try to implement here, but
I submit for consideration/discussion.


* As with "apk index" -> "apk mkindex", I'd find it easier if we aliased "apk
  update" to something less similar to "apk upgrade": perhaps "apk pull"?

* I'm not sure how things stand with the current version of apk-tools. But I
  know that at least with 2.3.4ish versions, "apk fix" would ignore
  /etc/apk/cache. That is, if I have foo-1.0 in the cache, but foo-1.1 is
  available on the repositories, then even if I explicitly request "apk fix -r
  foo" (as opposed to "apk fix -u foo"), I'd get upgraded to foo-1.1. This is
  surprising and undesirable. Could we change solver.c to prefer packages in
  /etc/apk/cache in such cases?

* It'd be nice if "apk version" also displayed which repository an upgrade
  would come from.

* for backwards compatibility, "apk fetch -R" is still honored, though "apk
  fetch -D" is now the preferred form. It may be confusing to have "apk fetch
  -D" and "apk fetch -R" have the same functionality, so we could consider
  immediately deprecating "apk fetch -R" more forcefully, for example by
  issuing a warning message.

* As I mentioned above, it'd be nice if "apk info -D/-R" recursed over more
  than a single level of dependencies, or at least if there were an option to
  do so.

* Is "--overlay-from-stdin" really a generic option, or like --clean-protected
  and --purge does this option too only apply to some of the applets?

* One of the patches below deprecates short-form "apk info -i", for reasons
  described in the commit. Now, the following proposal is probably just my own
  taste. But I'd suggest deprecating a bunch more of the short-form options:
  "apk -p", "apk fetch -s", "apk index -x", "apk upgrade -a", and all of "apk
  info -IPswt". In the first two cases, because these are unusual actions
  anyway and the short-form options aren't very memorable. It's easier and
  clearer in practice to just use the long form; and then the apk-tools option
  namespace will be clearer. In the third case ("apk index -x"), in part
  because this conflicts with the different meaning introduced above for "-x"
  wth "apk search." In part also because there's the confusing variety of "apk
  -X/--repository", "apk version -I/--indices", "apk index -x/--index". In the
  fourth case ("apk upgrade -a"), because it conflicts with the different
  meaning for "-a" ("--all") in some other apk commands. In the case of the
  "apk info" options: -I already has a different meaning for "apk version",
  plus I already suggested not using its relative "-i". Additionally, "-I" and
  "-P" are different in the character of their behavior from other capital
  letter short-form options for "apk info" (-L, -W, -R, -D). It seems clearer
  to just use the long forms for "-I" and "-P"; plus these are going to be rare
  actions in any case. For "apk info -swt": it's hard to remember which
  output-selecting options have short-forms (and what they are) and which
  don't. It'd be cleanest to just honor "-d" for "--description" and have the
  other output options be long-form only. Also, "-s" for "apk info" would
  conflict with the meaning of "-s" for "apk fetch", if we chose to retain
  that.

* I don't think I understand the difference between "apk add foo" and "apk add
  -u/--upgrade foo". Perhaps I asked about this before, but if it was ever
  explained to me, it's not something I've kept track of.

* "apk info" and "apk search" have different output styles, and interact with
  "-q" and "-v" differently. Here is the current behavior:

    apk info:     list all installed packages, without -1.0-r0 suffixes
    apk info -v:  list all installed packages, with -1.0-r0 suffixes
    apk info -vv: list all installed packages, with -1.0-r0 suffixes, also list
                  descriptions
    apk info -v [moreoptions] packagename: machine-friendly output

    apk search substring:    list matching packages, with 1.0-r0 suffixes
    apk search -q substring: suppress -1.0-r0 suffixes
    apk search -v substring: list matching packages plus descriptions, on one line

  I observe also that "apk info" always seems to ignore "-q", and "apk version
  -q" is, perversely, much more verbose than "apk version".
  
  This is all confusing and hard to remember. It'd be nice if we could
  standardize on a single mapping between output formats and options, perhaps
  following the pattern of "apk search".



Dubiousjim (15):
  cosmetic changes
  main dependencies -> 'world'
  clarify "apk version" usage
  tweak "apk fix" usage
  reword upgrade messages
  move -U option to applets that use it
  add -R and -D options
  clarify "apk info -R" vs "apk search -R"
  Allow "apk search -x" for -e
  remove "apk info -i" short option
  Prefer "apk mkindex" over "apk index"
  reorder some options in usage messages
  more usage reordering (apk.c)
  move --purge from generic options to applets that use it
  move --clean-protected from generic options to applets that use it

 src/add.c         | 21 ++++++++++++++++++---
 src/apk.c         | 41 ++++++++++++++---------------------------
 src/apk_package.h |  2 +-
 src/archive.c     |  2 +-
 src/audit.c       |  4 +++-
 src/database.c    | 14 ++++++--------
 src/del.c         | 16 ++++++++++++++--
 src/dot.c         |  6 +++++-
 src/fetch.c       |  8 +++++++-
 src/fix.c         | 22 +++++++++++++++++++---
 src/index.c       | 17 +++++++++++++++--
 src/info.c        | 26 ++++++++++++++++----------
 src/lua-apk.c     |  2 +-
 src/search.c      | 14 +++++++++++---
 src/upgrade.c     | 18 ++++++++++++++++--
 src/ver.c         | 17 +++++++++++------
 16 files changed, 158 insertions(+), 72 deletions(-)

-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 01/15] cosmetic changes

Details
Message ID
<7a986f63d724ba3626fbd6e0f75aaab32fecf884.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361326
DKIM signature
missing
Download raw message
Patch: +21 -22
---
 src/add.c         |  5 +++--
 src/apk.c         |  2 +-
 src/apk_package.h |  2 +-
 src/archive.c     |  2 +-
 src/database.c    | 14 ++++++--------
 src/dot.c         |  2 +-
 src/fetch.c       |  2 +-
 src/index.c       |  2 +-
 src/info.c        |  4 ++--
 src/lua-apk.c     |  2 +-
 src/search.c      |  2 +-
 src/ver.c         |  4 ++--
 12 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/src/add.c b/src/add.c
index 08fbf37..16e8dd1 100644
--- a/src/add.c
+++ b/src/add.c
@@ -154,14 +154,15 @@ static struct apk_option add_options[] = {
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
	{ 't',		"virtual",
	  "Instead of adding all the packages to 'world', create a new virtual "
	  "package with the listed dependencies and add that to 'world'. The "
	  "package with the listed dependencies and add that to 'world'; the "
	  "actions of the command are easily reverted by deleting the virtual "
	  "package", required_argument, "NAME" },
};

static struct apk_applet apk_add = {
	.name = "add",
	.help = "Add/update PACKAGEs to main dependencies and install them",
	.help = "Add PACKAGEs to main dependencies and install (or upgrade) "
		"them, while ensuring that all dependencies are met",
	.arguments = "PACKAGE...",
	.open_flags = APK_OPENF_WRITE,
	.context_size = sizeof(struct add_ctx),
diff --git a/src/apk.c b/src/apk.c
index 7739079..17e87d5 100644
--- a/src/apk.c
+++ b/src/apk.c
@@ -42,7 +42,7 @@ static struct apk_option generic_options[] = {
	{ 'X', "repository",	"Use packages from REPO",
				required_argument, "REPO" },
	{ 'q', "quiet",		"Print less information" },
	{ 'v', "verbose",	"Print more information" },
	{ 'v', "verbose",	"Print more information (can be doubled)" },
	{ 'i', "interactive",	"Ask confirmation for certain operations" },
	{ 'V', "version",	"Print program version and exit" },
	{ 'f', "force",		"Do what was asked even if it looks dangerous" },
diff --git a/src/apk_package.h b/src/apk_package.h
index 8945cd8..0d61e23 100644
--- a/src/apk_package.h
+++ b/src/apk_package.h
@@ -1,4 +1,4 @@
/* apk_database.h - Alpine Package Keeper (APK)
/* apk_package.h - Alpine Package Keeper (APK)
 *
 * Copyright (C) 2005-2008 Natanael Copa <n@tanael.org>
 * Copyright (C) 2008-2011 Timo Teräs <timo.teras@iki.fi>
diff --git a/src/archive.c b/src/archive.c
index 8f22f42..771e548 100644
--- a/src/archive.c
+++ b/src/archive.c
@@ -45,7 +45,7 @@ struct tar_header {
	char devmajor[8];   /* 329-336 */
	char devminor[8];   /* 337-344 */
	char prefix[155];   /* 345-499 */
	char padding[12];   /* 500-512 */
	char padding[12];   /* 500-511 */
};

struct apk_tar_digest_info {
diff --git a/src/database.c b/src/database.c
index d4becb9..33f7af8 100644
--- a/src/database.c
+++ b/src/database.c
@@ -1119,12 +1119,10 @@ static int apk_db_read_state(struct apk_database *db, int flags)
	int r;

	/* Read:
	 * 1. installed repository
	 * 2. source repositories
	 * 3. master dependencies
	 * 4. package statuses
	 * 5. files db
	 * 6. script db
	 * 1. /etc/apk/world
	 * 2. installed packages db
	 * 3. triggers db
	 * 4. scripts db
	 */
	if (!(flags & APK_OPENF_NO_WORLD)) {
		blob = world = apk_blob_from_file(db->root_fd, apk_world_file);
@@ -1574,14 +1572,14 @@ int apk_db_open(struct apk_database *db, struct apk_db_options *dbopts)
		db->cache_fd = fd;
		if ((dbopts->open_flags & (APK_OPENF_WRITE | APK_OPENF_CACHE_WRITE)) &&
		    fstatvfs(fd, &stvfs) == 0 && (stvfs.f_flag & ST_RDONLY) != 0) {
			/* remount cache read-write */
			/* remount cache read/write */
			db->cache_remount_dir = find_mountpoint(db->root_fd, db->cache_dir);
			if (db->cache_remount_dir == NULL) {
				apk_warning("Unable to find cache directory mount point");
			} else if (do_remount(db->cache_remount_dir, "rw") != 0) {
				free(db->cache_remount_dir);
				db->cache_remount_dir = NULL;
				apk_error("Unable to remount cache read-write");
				apk_error("Unable to remount cache read/write");
				r = EROFS;
				goto ret_r;
			}
diff --git a/src/dot.c b/src/dot.c
index 6738682..ccf5435 100644
--- a/src/dot.c
+++ b/src/dot.c
@@ -157,7 +157,7 @@ static int dot_main(void *pctx, struct apk_database *db, struct apk_string_array

static struct apk_option dot_options[] = {
	{ 0x10000,	"errors",	"Output only parts of the graph which are considered "
					"errorneus: e.g. cycles and missing packages" },
					"erroneous: e.g. cycles and missing packages" },
	{ 0x10001,	"installed",	"Consider only installed packages" },
};

diff --git a/src/fetch.c b/src/fetch.c
index 1d7389c..cf2fde7 100644
--- a/src/fetch.c
+++ b/src/fetch.c
@@ -260,7 +260,7 @@ static int fetch_main(void *pctx, struct apk_database *db, struct apk_string_arr

static struct apk_option fetch_options[] = {
	{ 'L', "link",		"Create hard links if possible" },
	{ 'R', "recursive",	"Fetch the PACKAGE and all it's dependencies" },
	{ 'R', "recursive",	"Fetch the PACKAGE and all its dependencies" },
	{ 's', "stdout",
	  "Dump the .apk to stdout (incompatible with -o and -R)" },
	{ 'o', "output",	"Directory to place the PACKAGEs to",
diff --git a/src/index.c b/src/index.c
index c61c78b..4a97911 100644
--- a/src/index.c
+++ b/src/index.c
@@ -245,7 +245,7 @@ static struct apk_option index_options[] = {
	{ 'd', "description", "Embed TEXT as description and version "
	  "information of the repository index",
	  required_argument, "TEXT" },
	{ 0x10000, "rewrite-arch", "Use ARCH as architery for all packages",
	{ 0x10000, "rewrite-arch", "Use ARCH as architecture for all packages",
	  required_argument, "ARCH" },
};

diff --git a/src/info.c b/src/info.c
index 9eb9e78..9a9154e 100644
--- a/src/info.c
+++ b/src/info.c
@@ -419,8 +419,8 @@ static struct apk_option info_options[] = {
	{ 'P', "provides",	"List virtual packages provided by PACKAGE" },
	{ 'r', "rdepends",	"List all packages depending on PACKAGE" },
	{ 0x10000, "replaces",	"List packages whom files PACKAGE might replace" },
	{ 'i', "install-if",	"List the PACKAGE's install-if rule" },
	{ 'I', "rinstall-if",	"List all packages having install-if referencing PACKAGE" },
	{ 'i', "install-if",	"List the PACKAGE's install_if rule" },
	{ 'I', "rinstall-if",	"List all packages having install_if referencing PACKAGE" },
	{ 'w', "webpage",	"Show URL for more information about PACKAGE" },
	{ 's', "size",		"Show installed size of PACKAGE" },
	{ 'd', "description",	"Print description for PACKAGE" },
diff --git a/src/lua-apk.c b/src/lua-apk.c
index 28eee61..bae0ee7 100644
--- a/src/lua-apk.c
+++ b/src/lua-apk.c
@@ -75,7 +75,7 @@ static int Pversion_compare(lua_State *L)
}

/* version_is_less(verstr1, verstr2)
   returns either '<', '=' or '>'
   returns whether version is '<'
*/
static int Pversion_is_less(lua_State *L)
{
diff --git a/src/search.c b/src/search.c
index 2b7b5e1..7ccf98a 100644
--- a/src/search.c
+++ b/src/search.c
@@ -1,4 +1,4 @@
/* info.c - Alpine Package Keeper (APK)
/* search.c - Alpine Package Keeper (APK)
 *
 * Copyright (C) 2005-2009 Natanael Copa <n@tanael.org>
 * Copyright (C) 2008-2011 Timo Teräs <timo.teras@iki.fi>
diff --git a/src/ver.c b/src/ver.c
index 94220a9..99da504 100644
--- a/src/ver.c
+++ b/src/ver.c
@@ -186,8 +186,8 @@ static struct apk_option ver_options[] = {
	{ 't', "test",		"Compare two given versions" },
	{ 'c', "check", 	"Check if the given version string is valid" },
	{ 'a', "all",		"Consider packages from all repository tags" },
	{ 'l', "limit",		"Limit output to packages with status matching one of LIMCHARS",
	  required_argument, "LIMCHARS" },
	{ 'l', "limit",		"Limit output to packages with status matching one of LIMCHARs",
	  required_argument, "LIMCHARs" },
};

static struct apk_applet apk_ver = {
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 02/15] main dependencies -> 'world'

Details
Message ID
<a316f5fc0d8460ac0f72c9832c3fa32813a547ba.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361327
DKIM signature
missing
Download raw message
Patch: +2 -2
---
 src/add.c | 2 +-
 src/del.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/add.c b/src/add.c
index 16e8dd1..2a0a36c 100644
--- a/src/add.c
+++ b/src/add.c
@@ -161,7 +161,7 @@ static struct apk_option add_options[] = {

static struct apk_applet apk_add = {
	.name = "add",
	.help = "Add PACKAGEs to main dependencies and install (or upgrade) "
	.help = "Add PACKAGEs to 'world' and install (or upgrade) "
		"them, while ensuring that all dependencies are met",
	.arguments = "PACKAGE...",
	.open_flags = APK_OPENF_WRITE,
diff --git a/src/del.c b/src/del.c
index cd15415..7b5fd6c 100644
--- a/src/del.c
+++ b/src/del.c
@@ -135,7 +135,7 @@ static struct apk_option del_options[] = {

static struct apk_applet apk_del = {
	.name = "del",
	.help = "Remove PACKAGEs from the main dependencies and uninstall them",
	.help = "Remove PACKAGEs from 'world' and uninstall them",
	.arguments = "PACKAGE...",
	.open_flags = APK_OPENF_WRITE,
	.context_size = sizeof(struct del_ctx),
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 03/15] clarify "apk version" usage

Details
Message ID
<8d44ebf8d8cb40a536d78d2a4f5871fa247bb60e.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361328
DKIM signature
missing
Download raw message
Patch: +4 -3
---
 src/ver.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/ver.c b/src/ver.c
index 99da504..fc7df5a 100644
--- a/src/ver.c
+++ b/src/ver.c
@@ -183,8 +183,8 @@ static int ver_main(void *pctx, struct apk_database *db, struct apk_string_array

static struct apk_option ver_options[] = {
	{ 'I', "indexes",	"Print description and versions of indexes" },
	{ 't', "test",		"Compare two given versions" },
	{ 'c', "check", 	"Check if the given version string is valid" },
	{ 't', "test",		"Compare two given versions, output '<' '=' or '>'" },
	{ 'c', "check", 	"Check the given version strings, output any that are invalid" },
	{ 'a', "all",		"Consider packages from all repository tags" },
	{ 'l', "limit",		"Limit output to packages with status matching one of LIMCHARs",
	  required_argument, "LIMCHARs" },
@@ -192,7 +192,8 @@ static struct apk_option ver_options[] = {

static struct apk_applet apk_ver = {
	.name = "version",
	.help = "Compare package versions",
	.help = "Compare package versions (in installed database vs. available) "
		"or do tests on literal version strings (with or without -rN suffixes)",
	.open_flags = APK_OPENF_READ,
	.context_size = sizeof(struct ver_ctx),
	.num_options = ARRAY_SIZE(ver_options),
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 04/15] tweak "apk fix" usage

Details
Message ID
<b7760d67c4d8c59fab4a8ca53e2a3a5b22df1f60.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361329
DKIM signature
missing
Download raw message
Patch: +2 -2
---
 src/fix.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/fix.c b/src/fix.c
index 4672813..3a7a8e6 100644
--- a/src/fix.c
+++ b/src/fix.c
@@ -86,8 +86,8 @@ static int fix_main(void *pctx, struct apk_database *db, struct apk_string_array

static struct apk_option fix_options[] = {
	{ 'd',		"depends",	"Fix all dependencies too" },
	{ 'u',		"upgrade",	"Upgrade package if possible" },
	{ 'r',		"reinstall",	"Reinstall the package" },
	{ 'r',		"reinstall",	"Reinstall the package (default)" },
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
	{ 0x10000,	"directory-permissions", "Reset all directory permissions" },
};

-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 05/15] reword upgrade messages

Details
Message ID
<f5cd1516ff3764f1996294979e046f1464eed2e4.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361330
DKIM signature
missing
Download raw message
Patch: +2 -2
---
 src/upgrade.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/upgrade.c b/src/upgrade.c
index 9eb7890..0d7155a 100644
--- a/src/upgrade.c
+++ b/src/upgrade.c
@@ -64,7 +64,7 @@ int apk_do_self_upgrade(struct apk_database *db, unsigned short solver_flags)
		goto ret;

	if (apk_flags & APK_SIMULATE) {
		apk_warning("This simulation is not reliable as apk-tools upgrade is available.");
		apk_warning("This simulation is not reliable if apk-tools upgrade is available.");
		goto ret;
	}

@@ -72,7 +72,7 @@ int apk_do_self_upgrade(struct apk_database *db, unsigned short solver_flags)
	apk_solver_commit_changeset(db, &changeset, db->world);
	apk_db_close(db);

	apk_message("Continuing the upgrade transaction with new apk-tools:");
	apk_message("Continuing the upgrade transaction:");
	for (r = 0; apk_argv[r] != NULL; r++)
		;
	apk_argv[r] = "--no-self-upgrade";
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 06/15] move -U option to applets that use it

Details
Message ID
<59171458300c7aaaf33babda6cd5a8dc0601b90e.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361331
DKIM signature
missing
Download raw message
Patch: +32 -4
---
 src/add.c     | 4 ++++
 src/apk.c     | 4 ----
 src/dot.c     | 4 ++++
 src/fetch.c   | 4 ++++
 src/fix.c     | 4 ++++
 src/info.c    | 4 ++++
 src/search.c  | 4 ++++
 src/upgrade.c | 4 ++++
 src/ver.c     | 4 ++++
 9 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/src/add.c b/src/add.c
index 2a0a36c..832e601 100644
--- a/src/add.c
+++ b/src/add.c
@@ -36,6 +36,9 @@ static int add_parse(void *ctx, struct apk_db_options *dbopts,
	case 't':
		actx->virtpkg = optarg;
		break;
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	default:
		return -1;
	}
@@ -151,6 +154,7 @@ static int add_main(void *ctx, struct apk_database *db, struct apk_string_array

static struct apk_option add_options[] = {
	{ 0x10000,	"initdb",	"Initialize database" },
	{ 'U',          "update-cache",	"Update the repository cache first" },
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
	{ 't',		"virtual",
	  "Instead of adding all the packages to 'world', create a new virtual "
diff --git a/src/apk.c b/src/apk.c
index 17e87d5..a1b26fb 100644
--- a/src/apk.c
+++ b/src/apk.c
@@ -46,7 +46,6 @@ static struct apk_option generic_options[] = {
	{ 'i', "interactive",	"Ask confirmation for certain operations" },
	{ 'V', "version",	"Print program version and exit" },
	{ 'f', "force",		"Do what was asked even if it looks dangerous" },
	{ 'U', "update-cache",	"Update the repository cache" },
	{ 0x101, "progress",	"Show a progress bar" },
	{ 0x10f, "progress-fd",	"Write progress to fd", required_argument, "FD" },
	{ 0x110, "no-progress",	"Disable progress bar even for TTYs" },
@@ -378,9 +377,6 @@ int main(int argc, char **argv)
		case 'i':
			apk_flags |= APK_INTERACTIVE;
			break;
		case 'U':
			apk_flags |= APK_UPDATE_CACHE;
			break;
		case 0x101:
			apk_flags |= APK_PROGRESS;
			break;
diff --git a/src/dot.c b/src/dot.c
index ccf5435..42a83fb 100644
--- a/src/dot.c
+++ b/src/dot.c
@@ -37,6 +37,9 @@ static int dot_parse(void *pctx, struct apk_db_options *dbopts,
		ctx->installed_only = 1;
		dbopts->open_flags &= ~APK_OPENF_NO_INSTALLED;
		break;
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	default:
		return -1;
	}
@@ -156,6 +159,7 @@ static int dot_main(void *pctx, struct apk_database *db, struct apk_string_array
}

static struct apk_option dot_options[] = {
	{ 'U',          "update-cache",	"Update the repository cache first" },
	{ 0x10000,	"errors",	"Output only parts of the graph which are considered "
					"erroneous: e.g. cycles and missing packages" },
	{ 0x10001,	"installed",	"Consider only installed packages" },
diff --git a/src/fetch.c b/src/fetch.c
index cf2fde7..60c31f4 100644
--- a/src/fetch.c
+++ b/src/fetch.c
@@ -73,6 +73,9 @@ static int fetch_parse(void *ctx, struct apk_db_options *dbopts,
	struct fetch_ctx *fctx = (struct fetch_ctx *) ctx;

	switch (optch) {
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	case 'R':
		fctx->flags |= FETCH_RECURSIVE;
		break;
@@ -259,6 +262,7 @@ static int fetch_main(void *pctx, struct apk_database *db, struct apk_string_arr
}

static struct apk_option fetch_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'L', "link",		"Create hard links if possible" },
	{ 'R', "recursive",	"Fetch the PACKAGE and all its dependencies" },
	{ 's', "stdout",
diff --git a/src/fix.c b/src/fix.c
index 3a7a8e6..e772bd9 100644
--- a/src/fix.c
+++ b/src/fix.c
@@ -30,6 +30,9 @@ static int fix_parse(void *pctx, struct apk_db_options *dbopts,
	case 'd':
		ctx->fix_depends = 1;
		break;
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	case 'u':
		ctx->solver_flags |= APK_SOLVERF_UPGRADE;
		break;
@@ -85,6 +88,7 @@ static int fix_main(void *pctx, struct apk_database *db, struct apk_string_array
}

static struct apk_option fix_options[] = {
	{ 'U',          "update-cache",	"Update the repository cache first" },
	{ 'd',		"depends",	"Fix all dependencies too" },
	{ 'r',		"reinstall",	"Reinstall the package (default)" },
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
diff --git a/src/info.c b/src/info.c
index 9a9154e..f4d5b92 100644
--- a/src/info.c
+++ b/src/info.c
@@ -344,6 +344,9 @@ static int info_parse(void *pctx, struct apk_db_options *dbopts,
		ctx->action = info_who_owns;
		dbopts->open_flags |= APK_OPENF_NO_REPOS;
		break;
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	case 'w':
		ctx->subaction_mask |= APK_INFO_URL;
		break;
@@ -412,6 +415,7 @@ static int info_main(void *ctx, struct apk_database *db, struct apk_string_array
}

static struct apk_option info_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'L', "contents",	"List contents of the PACKAGE" },
	{ 'e', "installed",	"Check if PACKAGE is installed" },
	{ 'W', "who-owns",	"Print the package owning the specified file" },
diff --git a/src/search.c b/src/search.c
index 7ccf98a..ef3d254 100644
--- a/src/search.c
+++ b/src/search.c
@@ -70,6 +70,9 @@ static int search_parse(void *ctx, struct apk_db_options *dbopts,
	struct search_ctx *ictx = (struct search_ctx *) ctx;

	switch (optch) {
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	case 'a':
		ictx->show_all = 1;
		break;
@@ -164,6 +167,7 @@ static int search_main(void *pctx, struct apk_database *db, struct apk_string_ar
}

static struct apk_option search_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'a', "all",		"Show all package versions (instead of latest only)" },
	{ 'd', "description",	"Search package descriptions (implies -a)" },
	{ 'e', "exact",		"Require exact match (instead of substring match)" },
diff --git a/src/upgrade.c b/src/upgrade.c
index 0d7155a..020fda0 100644
--- a/src/upgrade.c
+++ b/src/upgrade.c
@@ -32,6 +32,9 @@ static int upgrade_parse(void *ctx, struct apk_db_options *dbopts,
	case 0x10000:
		uctx->no_self_upgrade = 1;
		break;
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	case 'a':
		uctx->solver_flags |= APK_SOLVERF_AVAILABLE;
		break;
@@ -129,6 +132,7 @@ static int upgrade_main(void *ctx, struct apk_database *db, struct apk_string_ar
}

static struct apk_option upgrade_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'a', "available",
	  "Resets versioned world dependencies, and changes to prefer "
	  "replacing or downgrading packages (instead of holding them) "
diff --git a/src/ver.c b/src/ver.c
index fc7df5a..e15eaeb 100644
--- a/src/ver.c
+++ b/src/ver.c
@@ -90,6 +90,9 @@ static int ver_parse(void *ctx, struct apk_db_options *dbopts,
	case 'a':
		ictx->all_tags = 1;
		break;
	case 'U':
		apk_flags |= APK_UPDATE_CACHE;
		break;
	default:
		return -1;
	}
@@ -182,6 +185,7 @@ static int ver_main(void *pctx, struct apk_database *db, struct apk_string_array
}

static struct apk_option ver_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'I', "indexes",	"Print description and versions of indexes" },
	{ 't', "test",		"Compare two given versions, output '<' '=' or '>'" },
	{ 'c', "check", 	"Check the given version strings, output any that are invalid" },
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 07/15] add -R and -D options

Details
Message ID
<f95d9046c93a25cc0521e3c6c8f01bef01a0a8f7.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361332
DKIM signature
missing
Download raw message
Patch: +29 -16
Also add infrastructure for short-option-only synonyms
---
 src/apk.c    | 17 +++++++++--------
 src/audit.c  |  4 +++-
 src/del.c    |  4 +++-
 src/fetch.c  |  4 +++-
 src/fix.c    |  4 +++-
 src/info.c   |  8 +++++---
 src/search.c |  4 +++-
 7 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/src/apk.c b/src/apk.c
index a1b26fb..3e3461c 100644
--- a/src/apk.c
+++ b/src/apk.c
@@ -110,13 +110,14 @@ static void print_usage(const char *cmd, const char *args, int num_opts,
	int i, j;

	indent.x = printf("\nusage: apk %s", cmd) - 1;
	for (i = 0; i < num_opts; i++) {
		j = 0;
		word[j++] = '[';
		j += format_option(&word[j], sizeof(word) - j, &opts[i], "|");
		word[j++] = ']';
		apk_print_indented(&indent, APK_BLOB_PTR_LEN(word, j));
	}
	for (i = 0; i < num_opts; i++)
		if (opts[i].name != NULL) {
			j = 0;
			word[j++] = '[';
			j += format_option(&word[j], sizeof(word) - j, &opts[i], "|");
			word[j++] = ']';
			apk_print_indented(&indent, APK_BLOB_PTR_LEN(word, j));
		}
	if (args != NULL)
		apk_print_indented(&indent, APK_BLOB_STR(args));
	printf("\n");
@@ -229,7 +230,7 @@ static void merge_options(struct option *opts, struct apk_option *ao, int num)
	int i;

	for (i = 0; i < num; i++, opts++, ao++) {
		opts->name = ao->name;
		opts->name = ao->name ?: "";
		opts->has_arg = ao->has_arg;
		opts->flag = NULL;
		opts->val = ao->val;
diff --git a/src/audit.c b/src/audit.c
index 1b82c28..fb92aff 100644
--- a/src/audit.c
+++ b/src/audit.c
@@ -52,6 +52,7 @@ static int audit_parse(void *ctx, struct apk_db_options *dbopts,
		actx->packages_only = 1;
		break;
	case 'r':
	case 'R':
		actx->recursive = 1;
		break;
	default:
@@ -279,7 +280,8 @@ static struct apk_option audit_options[] = {
			     "protected_paths.d) that need to be backed up" },
	{ 0x10001, "system", "Verify checksums of all installed non-configuration files " },
	{ 0x10002, "check-permissions", "Check file and directory uid/gid/mode too" },
	{ 'r', "recursive",  "List individually all entries in new directories" },
	{ 'R', "recursive",  "List individually all entries in new directories" },
	{ 'r', NULL,	     "Synonym for -R (deprecated)" },
	{ 0x10003, "packages", "List only the changed packages (or names only with -q)" },
};

diff --git a/src/del.c b/src/del.c
index 7b5fd6c..f268b33 100644
--- a/src/del.c
+++ b/src/del.c
@@ -27,6 +27,7 @@ static int del_parse(void *pctx, struct apk_db_options *db,

	switch (optch) {
	case 'r':
	case 'R':
		ctx->recursive_delete = 1;
		break;
	default:
@@ -129,8 +130,9 @@ static int del_main(void *pctx, struct apk_database *db, struct apk_string_array
}

static struct apk_option del_options[] = {
	{ 'r', "rdepends",	"Recursively delete all top-level reverse "
	{ 'R', "rdepends",	"Recursively delete all top-level reverse "
				"dependencies too" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
};

static struct apk_applet apk_del = {
diff --git a/src/fetch.c b/src/fetch.c
index 60c31f4..059f1c8 100644
--- a/src/fetch.c
+++ b/src/fetch.c
@@ -77,6 +77,7 @@ static int fetch_parse(void *ctx, struct apk_db_options *dbopts,
		apk_flags |= APK_UPDATE_CACHE;
		break;
	case 'R':
	case 'D':
		fctx->flags |= FETCH_RECURSIVE;
		break;
	case 's':
@@ -264,7 +265,8 @@ static int fetch_main(void *pctx, struct apk_database *db, struct apk_string_arr
static struct apk_option fetch_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'L', "link",		"Create hard links if possible" },
	{ 'R', "recursive",	"Fetch the PACKAGE and all its dependencies" },
	{ 'D', "depends",	"Fetch the PACKAGE and all its dependencies" },
	{ 'R', "recursive",	"Synonyms for -D (deprecated)" },
	{ 's', "stdout",
	  "Dump the .apk to stdout (incompatible with -o and -R)" },
	{ 'o', "output",	"Directory to place the PACKAGEs to",
diff --git a/src/fix.c b/src/fix.c
index e772bd9..b59af0b 100644
--- a/src/fix.c
+++ b/src/fix.c
@@ -28,6 +28,7 @@ static int fix_parse(void *pctx, struct apk_db_options *dbopts,
	struct fix_ctx *ctx = (struct fix_ctx *) pctx;
	switch (optch) {
	case 'd':
	case 'D':
		ctx->fix_depends = 1;
		break;
	case 'U':
@@ -89,7 +90,8 @@ static int fix_main(void *pctx, struct apk_database *db, struct apk_string_array

static struct apk_option fix_options[] = {
	{ 'U',          "update-cache",	"Update the repository cache first" },
	{ 'd',		"depends",	"Fix all dependencies too" },
	{ 'D',		"depends",	"Fix all dependencies too" },
	{ 'd',          NULL,	        "Synonym for -D (deprecated)" },
	{ 'r',		"reinstall",	"Reinstall the package (default)" },
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
	{ 0x10000,	"directory-permissions", "Reset all directory permissions" },
diff --git a/src/info.c b/src/info.c
index f4d5b92..6859268 100644
--- a/src/info.c
+++ b/src/info.c
@@ -350,13 +350,14 @@ static int info_parse(void *pctx, struct apk_db_options *dbopts,
	case 'w':
		ctx->subaction_mask |= APK_INFO_URL;
		break;
	case 'R':
	case 'D':
		ctx->subaction_mask |= APK_INFO_DEPENDS;
		break;
	case 'P':
		ctx->subaction_mask |= APK_INFO_PROVIDES;
		break;
	case 'r':
	case 'R':
		ctx->subaction_mask |= APK_INFO_RDEPENDS;
		break;
	case 'I':
@@ -419,9 +420,10 @@ static struct apk_option info_options[] = {
	{ 'L', "contents",	"List contents of the PACKAGE" },
	{ 'e', "installed",	"Check if PACKAGE is installed" },
	{ 'W', "who-owns",	"Print the package owning the specified file" },
	{ 'R', "depends",	"List packages that the PACKAGE depends on" },
	{ 'D', "depends",	"List packages that the PACKAGE (directly) depends on" },
	{ 'R', "rdepends",	"List all packages (directly) depending on PACKAGE" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
	{ 'P', "provides",	"List virtual packages provided by PACKAGE" },
	{ 'r', "rdepends",	"List all packages depending on PACKAGE" },
	{ 0x10000, "replaces",	"List packages whom files PACKAGE might replace" },
	{ 'i', "install-if",	"List the PACKAGE's install_if rule" },
	{ 'I', "rinstall-if",	"List all packages having install_if referencing PACKAGE" },
diff --git a/src/search.c b/src/search.c
index ef3d254..e5044a9 100644
--- a/src/search.c
+++ b/src/search.c
@@ -88,6 +88,7 @@ static int search_parse(void *ctx, struct apk_db_options *dbopts,
		ictx->print_package = print_origin_name;
		break;
	case 'r':
	case 'R':
		ictx->print_result = print_rdepends;
		break;
	default:
@@ -172,7 +173,8 @@ static struct apk_option search_options[] = {
	{ 'd', "description",	"Search package descriptions (implies -a)" },
	{ 'e', "exact",		"Require exact match (instead of substring match)" },
	{ 'o', "origin",	"Print origin package name instead of the subpackage" },
	{ 'r', "rdepends",	"Print reverse dependencies of package" },
	{ 'R', "rdepends",	"Print reverse dependencies of package" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
};

static struct apk_applet apk_search = {
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 08/15] clarify "apk info -R" vs "apk search -R"

Details
Message ID
<ee3f7f5fba33dcfe5ec65ab03d6c7021527b2b61.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361333
DKIM signature
missing
Download raw message
Patch: +2 -2
---
 src/info.c   | 2 +-
 src/search.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/info.c b/src/info.c
index 6859268..578e118 100644
--- a/src/info.c
+++ b/src/info.c
@@ -421,7 +421,7 @@ static struct apk_option info_options[] = {
	{ 'e', "installed",	"Check if PACKAGE is installed" },
	{ 'W', "who-owns",	"Print the package owning the specified file" },
	{ 'D', "depends",	"List packages that the PACKAGE (directly) depends on" },
	{ 'R', "rdepends",	"List all packages (directly) depending on PACKAGE" },
	{ 'R', "rdepends",	"List all installed packages (directly) depending on PACKAGE" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
	{ 'P', "provides",	"List virtual packages provided by PACKAGE" },
	{ 0x10000, "replaces",	"List packages whom files PACKAGE might replace" },
diff --git a/src/search.c b/src/search.c
index e5044a9..122affe 100644
--- a/src/search.c
+++ b/src/search.c
@@ -173,7 +173,7 @@ static struct apk_option search_options[] = {
	{ 'd', "description",	"Search package descriptions (implies -a)" },
	{ 'e', "exact",		"Require exact match (instead of substring match)" },
	{ 'o', "origin",	"Print origin package name instead of the subpackage" },
	{ 'R', "rdepends",	"Print reverse dependencies of package" },
	{ 'R', "rdepends",	"List all (installed and uninstalled) packages depending on PACKAGE" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
};

-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 09/15] Allow "apk search -x" for -e

Details
Message ID
<64e093a929f8a2363bdc54e43ddf08ba9741b46a.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361334
DKIM signature
missing
Download raw message
Patch: +3 -1
---
 src/search.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/search.c b/src/search.c
index 122affe..4ef804d 100644
--- a/src/search.c
+++ b/src/search.c
@@ -82,6 +82,7 @@ static int search_parse(void *ctx, struct apk_db_options *dbopts,
		ictx->show_all = 1;
		break;
	case 'e':
	case 'x':
		ictx->search_exact = 1;
		break;
	case 'o':
@@ -171,7 +172,8 @@ static struct apk_option search_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'a', "all",		"Show all package versions (instead of latest only)" },
	{ 'd', "description",	"Search package descriptions (implies -a)" },
	{ 'e', "exact",		"Require exact match (instead of substring match)" },
	{ 'x', "exact",		"Require exact match (instead of substring match)" },
	{ 'e', NULL,	        "Synonym for -x (deprecated)" },
	{ 'o', "origin",	"Print origin package name instead of the subpackage" },
	{ 'R', "rdepends",	"List all (installed and uninstalled) packages depending on PACKAGE" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 10/15] remove "apk info -i" short option

Details
Message ID
<b034c12d8f202fd818722952b5bd3e2be1450f98.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361335
DKIM signature
missing
Download raw message
Patch: +2 -2
I'm not sure if either the short or long options work presently (try it with
abuildhelper). But in any case, I noticed in an earlier version of apk-tools
that the short option wasn't working, perhaps because the generic command-line
option '-i' is parsed first. This option for "apk info" is uncommon enough that
a short form (polluting the usage namespace) doesn't seem necessary.

Would be nice to also delete the short option -I (leaving just the long options
--install-if and --rinstall-if), but I haven't implemented that here.
---
 src/info.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/info.c b/src/info.c
index 578e118..62866eb 100644
--- a/src/info.c
+++ b/src/info.c
@@ -363,7 +363,7 @@ static int info_parse(void *pctx, struct apk_db_options *dbopts,
	case 'I':
		ctx->subaction_mask |= APK_INFO_INSTALL_IF;
		break;
	case 'i':
	case 0x10001:
		ctx->subaction_mask |= APK_INFO_RINSTALL_IF;
		break;
	case 's':
@@ -425,7 +425,7 @@ static struct apk_option info_options[] = {
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
	{ 'P', "provides",	"List virtual packages provided by PACKAGE" },
	{ 0x10000, "replaces",	"List packages whom files PACKAGE might replace" },
	{ 'i', "install-if",	"List the PACKAGE's install_if rule" },
	{ 0x10001, "install-if", "List the PACKAGE's install_if rule" },
	{ 'I', "rinstall-if",	"List all packages having install_if referencing PACKAGE" },
	{ 'w', "webpage",	"Show URL for more information about PACKAGE" },
	{ 's', "size",		"Show installed size of PACKAGE" },
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 11/15] Prefer "apk mkindex" over "apk index"

Details
Message ID
<e5dcf0d7e18714dcc6c4a933a9bf7b718ba7f0a4.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361336
DKIM signature
missing
Download raw message
Patch: +14 -1
---
 src/index.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/index.c b/src/index.c
index 4a97911..dafb5fc 100644
--- a/src/index.c
+++ b/src/index.c
@@ -251,7 +251,7 @@ static struct apk_option index_options[] = {

static struct apk_applet apk_index = {
	.name = "index",
	.help = "Create repository index file from FILEs",
	.help = "Create repository index file from FILEs (deprecated, use mkindex instead)",
	.arguments = "FILE...",
	.open_flags = APK_OPENF_READ | APK_OPENF_NO_STATE | APK_OPENF_NO_REPOS,
	.context_size = sizeof(struct index_ctx),
@@ -263,3 +263,16 @@ static struct apk_applet apk_index = {

APK_DEFINE_APPLET(apk_index);

static struct apk_applet apk_mkindex = {
	.name = "mkindex",
	.help = "Create repository index file from FILEs",
	.arguments = "FILE...",
	.open_flags = APK_OPENF_READ | APK_OPENF_NO_STATE | APK_OPENF_NO_REPOS,
	.context_size = sizeof(struct index_ctx),
	.num_options = ARRAY_SIZE(index_options),
	.options = index_options,
	.parse = index_parse,
	.main = index_main,
};

APK_DEFINE_APPLET(apk_mkindex);
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 12/15] reorder some options in usage messages

Details
Message ID
<ceda4b4c855328f02648cc0caee2b0590bc6e21a.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361337
DKIM signature
missing
Download raw message
Patch: +10 -10
---
 src/add.c   | 2 +-
 src/audit.c | 4 ++--
 src/info.c  | 8 ++++----
 src/ver.c   | 6 +++---
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/add.c b/src/add.c
index 832e601..021b878 100644
--- a/src/add.c
+++ b/src/add.c
@@ -153,7 +153,6 @@ static int add_main(void *ctx, struct apk_database *db, struct apk_string_array
}

static struct apk_option add_options[] = {
	{ 0x10000,	"initdb",	"Initialize database" },
	{ 'U',          "update-cache",	"Update the repository cache first" },
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
	{ 't',		"virtual",
@@ -161,6 +160,7 @@ static struct apk_option add_options[] = {
	  "package with the listed dependencies and add that to 'world'; the "
	  "actions of the command are easily reverted by deleting the virtual "
	  "package", required_argument, "NAME" },
	{ 0x10000,	"initdb",	"Initialize database" },
};

static struct apk_applet apk_add = {
diff --git a/src/audit.c b/src/audit.c
index fb92aff..e913020 100644
--- a/src/audit.c
+++ b/src/audit.c
@@ -276,12 +276,12 @@ static int audit_main(void *ctx, struct apk_database *db, struct apk_string_arra
}

static struct apk_option audit_options[] = {
	{ 'R', "recursive",  "List individually all entries in new directories" },
	{ 'r', NULL,	     "Synonym for -R (deprecated)" },
	{ 0x10000, "backup", "List all modified configuration files (in "
			     "protected_paths.d) that need to be backed up" },
	{ 0x10001, "system", "Verify checksums of all installed non-configuration files " },
	{ 0x10002, "check-permissions", "Check file and directory uid/gid/mode too" },
	{ 'R', "recursive",  "List individually all entries in new directories" },
	{ 'r', NULL,	     "Synonym for -R (deprecated)" },
	{ 0x10003, "packages", "List only the changed packages (or names only with -q)" },
};

diff --git a/src/info.c b/src/info.c
index 62866eb..a68281c 100644
--- a/src/info.c
+++ b/src/info.c
@@ -420,18 +420,18 @@ static struct apk_option info_options[] = {
	{ 'L', "contents",	"List contents of the PACKAGE" },
	{ 'e', "installed",	"Check if PACKAGE is installed" },
	{ 'W', "who-owns",	"Print the package owning the specified file" },
	{ 'a', "all",		"Print all information about PACKAGE" },
	{ 'd', "description",	"Print description for PACKAGE" },
	{ 'D', "depends",	"List packages that the PACKAGE (directly) depends on" },
	{ 'R', "rdepends",	"List all installed packages (directly) depending on PACKAGE" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
	{ 's', "size",		"Show installed size of PACKAGE" },
	{ 'w', "webpage",	"Show URL for more information about PACKAGE" },
	{ 'P', "provides",	"List virtual packages provided by PACKAGE" },
	{ 0x10000, "replaces",	"List packages whom files PACKAGE might replace" },
	{ 0x10001, "install-if", "List the PACKAGE's install_if rule" },
	{ 'I', "rinstall-if",	"List all packages having install_if referencing PACKAGE" },
	{ 'w', "webpage",	"Show URL for more information about PACKAGE" },
	{ 's', "size",		"Show installed size of PACKAGE" },
	{ 'd', "description",	"Print description for PACKAGE" },
	{ 't', "triggers",	"Print active triggers of PACKAGE" },
	{ 'a', "all",		"Print all information about PACKAGE" },
};

static struct apk_applet apk_info = {
diff --git a/src/ver.c b/src/ver.c
index e15eaeb..567c15b 100644
--- a/src/ver.c
+++ b/src/ver.c
@@ -186,12 +186,12 @@ static int ver_main(void *pctx, struct apk_database *db, struct apk_string_array

static struct apk_option ver_options[] = {
	{ 'U', "update-cache",	"Update the repository cache first" },
	{ 'I', "indexes",	"Print description and versions of indexes" },
	{ 't', "test",		"Compare two given versions, output '<' '=' or '>'" },
	{ 'c', "check", 	"Check the given version strings, output any that are invalid" },
	{ 'a', "all",		"Consider packages from all repository tags" },
	{ 'l', "limit",		"Limit output to packages with status matching one of LIMCHARs",
	  required_argument, "LIMCHARs" },
	{ 'I', "indexes",	"Print description and versions of indexes" },
	{ 't', "test",		"Compare two given versions, output '<' '=' or '>'" },
	{ 'c', "check", 	"Check the given version strings, output any that are invalid" },
};

static struct apk_applet apk_ver = {
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 13/15] more usage reordering (apk.c)

Details
Message ID
<699a1abbe061db0a8412c3b246b2e4316a36e32a.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361338
DKIM signature
missing
Download raw message
Patch: +5 -5
---
 src/apk.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/apk.c b/src/apk.c
index 3e3461c..604378c 100644
--- a/src/apk.c
+++ b/src/apk.c
@@ -37,15 +37,15 @@ char **apk_argv;

static struct apk_option generic_options[] = {
	{ 'h', "help",		"Show generic help or applet specific help" },
	{ 'p', "root",		"Install packages to DIR",
				required_argument, "DIR" },
	{ 'X', "repository",	"Use packages from REPO",
				required_argument, "REPO" },
	{ 'V', "version",	"Print program version and exit" },
	{ 'q', "quiet",		"Print less information" },
	{ 'v', "verbose",	"Print more information (can be doubled)" },
	{ 'i', "interactive",	"Ask confirmation for certain operations" },
	{ 'V', "version",	"Print program version and exit" },
	{ 'f', "force",		"Do what was asked even if it looks dangerous" },
	{ 'p', "root",		"Install packages to DIR",
				required_argument, "DIR" },
	{ 'X', "repository",	"Use packages from REPO",
				required_argument, "REPO" },
	{ 0x101, "progress",	"Show a progress bar" },
	{ 0x10f, "progress-fd",	"Write progress to fd", required_argument, "FD" },
	{ 0x110, "no-progress",	"Disable progress bar even for TTYs" },
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 14/15] move --purge from generic options to applets that use it

Details
Message ID
<a3bf68da198793842a939f0694ee1a9e8d2dadac.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361339
DKIM signature
missing
Download raw message
Patch: +20 -5
---
 src/add.c     | 5 +++++
 src/apk.c     | 5 -----
 src/del.c     | 5 +++++
 src/fix.c     | 5 +++++
 src/upgrade.c | 5 +++++
 5 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/src/add.c b/src/add.c
index 021b878..ea4bd47 100644
--- a/src/add.c
+++ b/src/add.c
@@ -30,6 +30,9 @@ static int add_parse(void *ctx, struct apk_db_options *dbopts,
	case 0x10000:
		dbopts->open_flags |= APK_OPENF_CREATE;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
	case 'u':
		actx->solver_flags |= APK_SOLVERF_UPGRADE;
		break;
@@ -160,6 +163,8 @@ static struct apk_option add_options[] = {
	  "package with the listed dependencies and add that to 'world'; the "
	  "actions of the command are easily reverted by deleting the virtual "
	  "package", required_argument, "NAME" },
	{ 0x10002,      "purge",	"Delete also modified configuration files on "
				        "package removal" },
	{ 0x10000,	"initdb",	"Initialize database" },
};

diff --git a/src/apk.c b/src/apk.c
index 604378c..8c05d9f 100644
--- a/src/apk.c
+++ b/src/apk.c
@@ -51,8 +51,6 @@ static struct apk_option generic_options[] = {
	{ 0x110, "no-progress",	"Disable progress bar even for TTYs" },
	{ 0x102, "clean-protected", "Do not create .apk-new files to "
				"configuration dirs" },
	{ 0x106, "purge",	"Delete also modified configuration files on "
				"package removal" },
	{ 0x103, "allow-untrusted", "Blindly install packages with untrusted "
				"signatures or no signature at all" },
	{ 0x104, "simulate",	"Show what would be done without actually "
@@ -396,9 +394,6 @@ int main(int argc, char **argv)
		case 0x104:
			apk_flags |= APK_SIMULATE;
			break;
		case 0x106:
			apk_flags |= APK_PURGE;
			break;
		case 0x105:
			dbopts.lock_wait = atoi(optarg);
			break;
diff --git a/src/del.c b/src/del.c
index f268b33..bbf4080 100644
--- a/src/del.c
+++ b/src/del.c
@@ -30,6 +30,9 @@ static int del_parse(void *pctx, struct apk_db_options *db,
	case 'R':
		ctx->recursive_delete = 1;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
	default:
		return -1;
	}
@@ -133,6 +136,8 @@ static struct apk_option del_options[] = {
	{ 'R', "rdepends",	"Recursively delete all top-level reverse "
				"dependencies too" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
	{ 0x10002, "purge",	"Delete also modified configuration files on "
			        "package removal" },
};

static struct apk_applet apk_del = {
diff --git a/src/fix.c b/src/fix.c
index b59af0b..da08b73 100644
--- a/src/fix.c
+++ b/src/fix.c
@@ -43,6 +43,9 @@ static int fix_parse(void *pctx, struct apk_db_options *dbopts,
	case 0x10000:
		ctx->fix_directory_permissions = 1;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
	default:
		return -1;
	}
@@ -95,6 +98,8 @@ static struct apk_option fix_options[] = {
	{ 'r',		"reinstall",	"Reinstall the package (default)" },
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
	{ 0x10000,	"directory-permissions", "Reset all directory permissions" },
	{ 0x10002,      "purge",	"Delete also modified configuration files on "
				        "package removal" },
};

static struct apk_applet apk_fix = {
diff --git a/src/upgrade.c b/src/upgrade.c
index 020fda0..28ce020 100644
--- a/src/upgrade.c
+++ b/src/upgrade.c
@@ -41,6 +41,9 @@ static int upgrade_parse(void *ctx, struct apk_db_options *dbopts,
	case 'l':
		uctx->solver_flags |= APK_SOLVERF_LATEST;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
	default:
		return -1;
	}
@@ -141,6 +144,8 @@ static struct apk_option upgrade_options[] = {
	{ 'l', "latest",
	  "Select latest version of package (if it is not pinned), and "
	  "print error if it cannot be installed due to other dependencies" },
	{ 0x10002, "purge",	"Delete also modified configuration files on "
				"package removal" },
	{ 0x10000, "no-self-upgrade",
	  "Do not do early upgrade of 'apk-tools' package" },
};
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] [PATCH 15/15] move --clean-protected from generic options to applets that use it

Details
Message ID
<44680caf527959b025ef1105e72b10ff39d21e50.1372361242.git.dubiousjim@gmail.com>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372361340
DKIM signature
missing
Download raw message
Patch: +20 -5
---
 src/add.c     | 5 +++++
 src/apk.c     | 5 -----
 src/del.c     | 5 +++++
 src/fix.c     | 5 +++++
 src/upgrade.c | 5 +++++
 5 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/src/add.c b/src/add.c
index ea4bd47..e3baa74 100644
--- a/src/add.c
+++ b/src/add.c
@@ -30,6 +30,9 @@ static int add_parse(void *ctx, struct apk_db_options *dbopts,
	case 0x10000:
		dbopts->open_flags |= APK_OPENF_CREATE;
		break;
	case 0x10003:
		apk_flags |= APK_CLEAN_PROTECTED;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
@@ -163,6 +166,8 @@ static struct apk_option add_options[] = {
	  "package with the listed dependencies and add that to 'world'; the "
	  "actions of the command are easily reverted by deleting the virtual "
	  "package", required_argument, "NAME" },
	{ 0x10003,      "clean-protected", "Do not create .apk-new files in "
				        "configuration dirs" },
	{ 0x10002,      "purge",	"Delete also modified configuration files on "
				        "package removal" },
	{ 0x10000,	"initdb",	"Initialize database" },
diff --git a/src/apk.c b/src/apk.c
index 8c05d9f..c3709e7 100644
--- a/src/apk.c
+++ b/src/apk.c
@@ -49,8 +49,6 @@ static struct apk_option generic_options[] = {
	{ 0x101, "progress",	"Show a progress bar" },
	{ 0x10f, "progress-fd",	"Write progress to fd", required_argument, "FD" },
	{ 0x110, "no-progress",	"Disable progress bar even for TTYs" },
	{ 0x102, "clean-protected", "Do not create .apk-new files to "
				"configuration dirs" },
	{ 0x103, "allow-untrusted", "Blindly install packages with untrusted "
				"signatures or no signature at all" },
	{ 0x104, "simulate",	"Show what would be done without actually "
@@ -385,9 +383,6 @@ int main(int argc, char **argv)
		case 0x10f:
			apk_progress_fd = atoi(optarg);
			break;
		case 0x102:
			apk_flags |= APK_CLEAN_PROTECTED;
			break;
		case 0x103:
			apk_flags |= APK_ALLOW_UNTRUSTED;
			break;
diff --git a/src/del.c b/src/del.c
index bbf4080..21da5d1 100644
--- a/src/del.c
+++ b/src/del.c
@@ -30,6 +30,9 @@ static int del_parse(void *pctx, struct apk_db_options *db,
	case 'R':
		ctx->recursive_delete = 1;
		break;
	case 0x10003:
		apk_flags |= APK_CLEAN_PROTECTED;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
@@ -136,6 +139,8 @@ static struct apk_option del_options[] = {
	{ 'R', "rdepends",	"Recursively delete all top-level reverse "
				"dependencies too" },
	{ 'r', NULL,	        "Synonym for -R (deprecated)" },
	{ 0x10003,      "clean-protected", "Do not create .apk-new files in "
				        "configuration dirs" },
	{ 0x10002, "purge",	"Delete also modified configuration files on "
			        "package removal" },
};
diff --git a/src/fix.c b/src/fix.c
index da08b73..c04abe1 100644
--- a/src/fix.c
+++ b/src/fix.c
@@ -43,6 +43,9 @@ static int fix_parse(void *pctx, struct apk_db_options *dbopts,
	case 0x10000:
		ctx->fix_directory_permissions = 1;
		break;
	case 0x10003:
		apk_flags |= APK_CLEAN_PROTECTED;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
@@ -98,6 +101,8 @@ static struct apk_option fix_options[] = {
	{ 'r',		"reinstall",	"Reinstall the package (default)" },
	{ 'u',		"upgrade",	"Prefer to upgrade package" },
	{ 0x10000,	"directory-permissions", "Reset all directory permissions" },
	{ 0x10003,      "clean-protected", "Do not create .apk-new files in "
				        "configuration dirs" },
	{ 0x10002,      "purge",	"Delete also modified configuration files on "
				        "package removal" },
};
diff --git a/src/upgrade.c b/src/upgrade.c
index 28ce020..8a476e9 100644
--- a/src/upgrade.c
+++ b/src/upgrade.c
@@ -41,6 +41,9 @@ static int upgrade_parse(void *ctx, struct apk_db_options *dbopts,
	case 'l':
		uctx->solver_flags |= APK_SOLVERF_LATEST;
		break;
	case 0x10003:
		apk_flags |= APK_CLEAN_PROTECTED;
		break;
	case 0x10002:
		apk_flags |= APK_PURGE;
		break;
@@ -144,6 +147,8 @@ static struct apk_option upgrade_options[] = {
	{ 'l', "latest",
	  "Select latest version of package (if it is not pinned), and "
	  "print error if it cannot be installed due to other dependencies" },
	{ 0x10003, "clean-protected", "Do not create .apk-new files in "
				      "configuration dirs" },
	{ 0x10002, "purge",	"Delete also modified configuration files on "
				"package removal" },
	{ 0x10000, "no-self-upgrade",
-- 
1.8.3.1



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 01/15] cosmetic changes

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628111333.0723e0ce@ncopa-desktop.alpinelinux.org>
In-Reply-To
<7a986f63d724ba3626fbd6e0f75aaab32fecf884.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372410813
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:46 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> ---
>  src/add.c         |  5 +++--
>  src/apk.c         |  2 +-
>  src/apk_package.h |  2 +-
>  src/archive.c     |  2 +-
>  src/database.c    | 14 ++++++--------
>  src/dot.c         |  2 +-
>  src/fetch.c       |  2 +-
>  src/index.c       |  2 +-
>  src/info.c        |  4 ++--
>  src/lua-apk.c     |  2 +-
>  src/search.c      |  2 +-
>  src/ver.c         |  4 ++--
>  12 files changed, 21 insertions(+), 22 deletions(-)

Looks good to me. (a minor comment below)

acked-by: Natanael Copa <ncopa@alpinelinux.org>

> diff --git a/src/add.c b/src/add.c
> index 08fbf37..16e8dd1 100644
> --- a/src/add.c
> +++ b/src/add.c
> @@ -154,14 +154,15 @@ static struct apk_option add_options[] = {
>  	{ 'u',		"upgrade",	"Prefer to upgrade package" },
>  	{ 't',		"virtual",
>  	  "Instead of adding all the packages to 'world', create a new virtual "
> -	  "package with the listed dependencies and add that to 'world'. The "
> +	  "package with the listed dependencies and add that to 'world'; the "
>  	  "actions of the command are easily reverted by deleting the virtual "
>  	  "package", required_argument, "NAME" },
>  };
>  
>  static struct apk_applet apk_add = {
>  	.name = "add",
> -	.help = "Add/update PACKAGEs to main dependencies and install them",
> +	.help = "Add PACKAGEs to main dependencies and install (or upgrade) "
> +		"them, while ensuring that all dependencies are met",
>  	.arguments = "PACKAGE...",
>  	.open_flags = APK_OPENF_WRITE,
>  	.context_size = sizeof(struct add_ctx),

it could have been: (or upgrade, if -u is given)

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 02/15] main dependencies -> 'world'

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628111452.79f6c235@ncopa-desktop.alpinelinux.org>
In-Reply-To
<a316f5fc0d8460ac0f72c9832c3fa32813a547ba.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372410892
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:47 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> ---
>  src/add.c | 2 +-
>  src/del.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

ACK

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 03/15] clarify "apk version" usage

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628111903.04fbe4e7@ncopa-desktop.alpinelinux.org>
In-Reply-To
<8d44ebf8d8cb40a536d78d2a4f5871fa247bb60e.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372411143
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:48 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> ---
>  src/ver.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/src/ver.c b/src/ver.c
> index 99da504..fc7df5a 100644
> --- a/src/ver.c
> +++ b/src/ver.c
> @@ -183,8 +183,8 @@ static int ver_main(void *pctx, struct apk_database *db, struct apk_string_array
>  
>  static struct apk_option ver_options[] = {
>  	{ 'I', "indexes",	"Print description and versions of indexes" },
> -	{ 't', "test",		"Compare two given versions" },
> -	{ 'c', "check", 	"Check if the given version string is valid" },
> +	{ 't', "test",		"Compare two given versions, output '<' '=' or '>'" },
> +	{ 'c', "check", 	"Check the given version strings, output any that are invalid" },
>  	{ 'a', "all",		"Consider packages from all repository tags" },
>  	{ 'l', "limit",		"Limit output to packages with status matching one of LIMCHARs",
>  	  required_argument, "LIMCHARs" },

shouldn't it be a comma (,) in there?

...output '<', '=' or '>'

> @@ -192,7 +192,8 @@ static struct apk_option ver_options[] = {
>  
>  static struct apk_applet apk_ver = {
>  	.name = "version",
> -	.help = "Compare package versions",
> +	.help = "Compare package versions (in installed database vs. available) "
> +		"or do tests on literal version strings (with or without -rN suffixes)",
>  	.open_flags = APK_OPENF_READ,
>  	.context_size = sizeof(struct ver_ctx),
>  	.num_options = ARRAY_SIZE(ver_options),

Can we drop the "(with or without -rN suffixes)" part? it looks like -r -N options...

otherwise looks ok.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 04/15] tweak "apk fix" usage

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628111948.0922096b@ncopa-desktop.alpinelinux.org>
In-Reply-To
<b7760d67c4d8c59fab4a8ca53e2a3a5b22df1f60.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372411188
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:49 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> ---
>  src/fix.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/fix.c b/src/fix.c
> index 4672813..3a7a8e6 100644
> --- a/src/fix.c
> +++ b/src/fix.c
> @@ -86,8 +86,8 @@ static int fix_main(void *pctx, struct apk_database *db, struct apk_string_array
>  
>  static struct apk_option fix_options[] = {
>  	{ 'd',		"depends",	"Fix all dependencies too" },
> -	{ 'u',		"upgrade",	"Upgrade package if possible" },
> -	{ 'r',		"reinstall",	"Reinstall the package" },
> +	{ 'r',		"reinstall",	"Reinstall the package (default)" },
> +	{ 'u',		"upgrade",	"Prefer to upgrade package" },
>  	{ 0x10000,	"directory-permissions", "Reset all directory permissions" },
>  };
>  

ACK

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 05/15] reword upgrade messages

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628113101.0e552bd3@ncopa-desktop.alpinelinux.org>
In-Reply-To
<f5cd1516ff3764f1996294979e046f1464eed2e4.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372411861
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:50 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

I think there have been bugs recently that has made apk perform the self
upgrade at 'random'. The self-upgrade should only happen when apk-tools
or one of its dependencies are upgraded. Maybe it should self-upgrade
only when apk-tools itself needs upgrade. (dependencies should be ABI
compat so they should not have any effect on the result)

> ---
>  src/upgrade.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/upgrade.c b/src/upgrade.c
> index 9eb7890..0d7155a 100644
> --- a/src/upgrade.c
> +++ b/src/upgrade.c
> @@ -64,7 +64,7 @@ int apk_do_self_upgrade(struct apk_database *db, unsigned short solver_flags)
>  		goto ret;
>  
>  	if (apk_flags & APK_SIMULATE) {
> -		apk_warning("This simulation is not reliable as apk-tools upgrade is available.");
> +		apk_warning("This simulation is not reliable if apk-tools upgrade is available.");
>  		goto ret;
>  	}
>  

I think this warning will/should only be displayed when it would
perform a self-upgrade. Proper warning would probably be:

"This simulation is not reliable as apk-tools or its dependencies would be upgraded".

Or even better, make apk upgrade ignore when an apk-tools dependency is
upgraded and only perform self-upgrade when apk-tools itself only is
upgraded.

> @@ -72,7 +72,7 @@ int apk_do_self_upgrade(struct apk_database *db, unsigned short solver_flags)
>  	apk_solver_commit_changeset(db, &changeset, db->world);
>  	apk_db_close(db);
>  
> -	apk_message("Continuing the upgrade transaction with new apk-tools:");
> +	apk_message("Continuing the upgrade transaction:");
>  	for (r = 0; apk_argv[r] != NULL; r++)
>  		;
>  	apk_argv[r] = "--no-self-upgrade";


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 06/15] move -U option to applets that use it

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628113509.136ebe3c@ncopa-desktop.alpinelinux.org>
In-Reply-To
<59171458300c7aaaf33babda6cd5a8dc0601b90e.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372412109
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:51 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> ---
>  src/add.c     | 4 ++++
>  src/apk.c     | 4 ----
>  src/dot.c     | 4 ++++
>  src/fetch.c   | 4 ++++
>  src/fix.c     | 4 ++++
>  src/info.c    | 4 ++++
>  src/search.c  | 4 ++++
>  src/upgrade.c | 4 ++++
>  src/ver.c     | 4 ++++
>  9 files changed, 32 insertions(+), 4 deletions(-)

Since there are many applets using same option, I wonder if we could join them somehow?

It might not matter since I think the gcc optimizer will store only one
copy of the identical string constants.

-nc

> 
> diff --git a/src/add.c b/src/add.c
> index 2a0a36c..832e601 100644
> --- a/src/add.c
> +++ b/src/add.c
> @@ -36,6 +36,9 @@ static int add_parse(void *ctx, struct apk_db_options *dbopts,
>  	case 't':
>  		actx->virtpkg = optarg;
>  		break;
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	default:
>  		return -1;
>  	}
> @@ -151,6 +154,7 @@ static int add_main(void *ctx, struct apk_database *db, struct apk_string_array
>  
>  static struct apk_option add_options[] = {
>  	{ 0x10000,	"initdb",	"Initialize database" },
> +	{ 'U',          "update-cache",	"Update the repository cache first" },
>  	{ 'u',		"upgrade",	"Prefer to upgrade package" },
>  	{ 't',		"virtual",
>  	  "Instead of adding all the packages to 'world', create a new virtual "
> diff --git a/src/apk.c b/src/apk.c
> index 17e87d5..a1b26fb 100644
> --- a/src/apk.c
> +++ b/src/apk.c
> @@ -46,7 +46,6 @@ static struct apk_option generic_options[] = {
>  	{ 'i', "interactive",	"Ask confirmation for certain operations" },
>  	{ 'V', "version",	"Print program version and exit" },
>  	{ 'f', "force",		"Do what was asked even if it looks dangerous" },
> -	{ 'U', "update-cache",	"Update the repository cache" },
>  	{ 0x101, "progress",	"Show a progress bar" },
>  	{ 0x10f, "progress-fd",	"Write progress to fd", required_argument, "FD" },
>  	{ 0x110, "no-progress",	"Disable progress bar even for TTYs" },
> @@ -378,9 +377,6 @@ int main(int argc, char **argv)
>  		case 'i':
>  			apk_flags |= APK_INTERACTIVE;
>  			break;
> -		case 'U':
> -			apk_flags |= APK_UPDATE_CACHE;
> -			break;
>  		case 0x101:
>  			apk_flags |= APK_PROGRESS;
>  			break;
> diff --git a/src/dot.c b/src/dot.c
> index ccf5435..42a83fb 100644
> --- a/src/dot.c
> +++ b/src/dot.c
> @@ -37,6 +37,9 @@ static int dot_parse(void *pctx, struct apk_db_options *dbopts,
>  		ctx->installed_only = 1;
>  		dbopts->open_flags &= ~APK_OPENF_NO_INSTALLED;
>  		break;
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	default:
>  		return -1;
>  	}
> @@ -156,6 +159,7 @@ static int dot_main(void *pctx, struct apk_database *db, struct apk_string_array
>  }
>  
>  static struct apk_option dot_options[] = {
> +	{ 'U',          "update-cache",	"Update the repository cache first" },
>  	{ 0x10000,	"errors",	"Output only parts of the graph which are considered "
>  					"erroneous: e.g. cycles and missing packages" },
>  	{ 0x10001,	"installed",	"Consider only installed packages" },
> diff --git a/src/fetch.c b/src/fetch.c
> index cf2fde7..60c31f4 100644
> --- a/src/fetch.c
> +++ b/src/fetch.c
> @@ -73,6 +73,9 @@ static int fetch_parse(void *ctx, struct apk_db_options *dbopts,
>  	struct fetch_ctx *fctx = (struct fetch_ctx *) ctx;
>  
>  	switch (optch) {
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	case 'R':
>  		fctx->flags |= FETCH_RECURSIVE;
>  		break;
> @@ -259,6 +262,7 @@ static int fetch_main(void *pctx, struct apk_database *db, struct apk_string_arr
>  }
>  
>  static struct apk_option fetch_options[] = {
> +	{ 'U', "update-cache",	"Update the repository cache first" },
>  	{ 'L', "link",		"Create hard links if possible" },
>  	{ 'R', "recursive",	"Fetch the PACKAGE and all its dependencies" },
>  	{ 's', "stdout",
> diff --git a/src/fix.c b/src/fix.c
> index 3a7a8e6..e772bd9 100644
> --- a/src/fix.c
> +++ b/src/fix.c
> @@ -30,6 +30,9 @@ static int fix_parse(void *pctx, struct apk_db_options *dbopts,
>  	case 'd':
>  		ctx->fix_depends = 1;
>  		break;
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	case 'u':
>  		ctx->solver_flags |= APK_SOLVERF_UPGRADE;
>  		break;
> @@ -85,6 +88,7 @@ static int fix_main(void *pctx, struct apk_database *db, struct apk_string_array
>  }
>  
>  static struct apk_option fix_options[] = {
> +	{ 'U',          "update-cache",	"Update the repository cache first" },
>  	{ 'd',		"depends",	"Fix all dependencies too" },
>  	{ 'r',		"reinstall",	"Reinstall the package (default)" },
>  	{ 'u',		"upgrade",	"Prefer to upgrade package" },
> diff --git a/src/info.c b/src/info.c
> index 9a9154e..f4d5b92 100644
> --- a/src/info.c
> +++ b/src/info.c
> @@ -344,6 +344,9 @@ static int info_parse(void *pctx, struct apk_db_options *dbopts,
>  		ctx->action = info_who_owns;
>  		dbopts->open_flags |= APK_OPENF_NO_REPOS;
>  		break;
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	case 'w':
>  		ctx->subaction_mask |= APK_INFO_URL;
>  		break;
> @@ -412,6 +415,7 @@ static int info_main(void *ctx, struct apk_database *db, struct apk_string_array
>  }
>  
>  static struct apk_option info_options[] = {
> +	{ 'U', "update-cache",	"Update the repository cache first" },
>  	{ 'L', "contents",	"List contents of the PACKAGE" },
>  	{ 'e', "installed",	"Check if PACKAGE is installed" },
>  	{ 'W', "who-owns",	"Print the package owning the specified file" },
> diff --git a/src/search.c b/src/search.c
> index 7ccf98a..ef3d254 100644
> --- a/src/search.c
> +++ b/src/search.c
> @@ -70,6 +70,9 @@ static int search_parse(void *ctx, struct apk_db_options *dbopts,
>  	struct search_ctx *ictx = (struct search_ctx *) ctx;
>  
>  	switch (optch) {
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	case 'a':
>  		ictx->show_all = 1;
>  		break;
> @@ -164,6 +167,7 @@ static int search_main(void *pctx, struct apk_database *db, struct apk_string_ar
>  }
>  
>  static struct apk_option search_options[] = {
> +	{ 'U', "update-cache",	"Update the repository cache first" },
>  	{ 'a', "all",		"Show all package versions (instead of latest only)" },
>  	{ 'd', "description",	"Search package descriptions (implies -a)" },
>  	{ 'e', "exact",		"Require exact match (instead of substring match)" },
> diff --git a/src/upgrade.c b/src/upgrade.c
> index 0d7155a..020fda0 100644
> --- a/src/upgrade.c
> +++ b/src/upgrade.c
> @@ -32,6 +32,9 @@ static int upgrade_parse(void *ctx, struct apk_db_options *dbopts,
>  	case 0x10000:
>  		uctx->no_self_upgrade = 1;
>  		break;
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	case 'a':
>  		uctx->solver_flags |= APK_SOLVERF_AVAILABLE;
>  		break;
> @@ -129,6 +132,7 @@ static int upgrade_main(void *ctx, struct apk_database *db, struct apk_string_ar
>  }
>  
>  static struct apk_option upgrade_options[] = {
> +	{ 'U', "update-cache",	"Update the repository cache first" },
>  	{ 'a', "available",
>  	  "Resets versioned world dependencies, and changes to prefer "
>  	  "replacing or downgrading packages (instead of holding them) "
> diff --git a/src/ver.c b/src/ver.c
> index fc7df5a..e15eaeb 100644
> --- a/src/ver.c
> +++ b/src/ver.c
> @@ -90,6 +90,9 @@ static int ver_parse(void *ctx, struct apk_db_options *dbopts,
>  	case 'a':
>  		ictx->all_tags = 1;
>  		break;
> +	case 'U':
> +		apk_flags |= APK_UPDATE_CACHE;
> +		break;
>  	default:
>  		return -1;
>  	}
> @@ -182,6 +185,7 @@ static int ver_main(void *pctx, struct apk_database *db, struct apk_string_array
>  }
>  
>  static struct apk_option ver_options[] = {
> +	{ 'U', "update-cache",	"Update the repository cache first" },
>  	{ 'I', "indexes",	"Print description and versions of indexes" },
>  	{ 't', "test",		"Compare two given versions, output '<' '=' or '>'" },
>  	{ 'c', "check", 	"Check the given version strings, output any that are invalid" },



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] futher apk ideas (WAS: [PATCH 00/15] apk-tools UI fixes/refinements)

Details
Message ID
<20130628163747.GB1712@zen.nyu.edu>
In-Reply-To
<20130628154631.4d18107d@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1372437467
DKIM signature
missing
Download raw message
Thanks Natanael and Timo for your comments. I'm glad we're mostly on the
same page about these things. Much of what I threw out was just to
invite reactions.

I'll have a look at what you've already committed and rebase the commits
Timo asked me to separate out, shortly. This is just to respond to some
of your comments.

I'll split out the discussion of -R/-D and the logging to separate
emails.


On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> 
> I will likely commit the minor clean ups to master before next tag. But
> the bulk of this, and the logging patch set would likely wait for 3.0.
> 
> The reason is we're planning to backport apk-tools 2.4.x to our -stable
> alpine releases and do not want to break things there.

Makes perfect sense.


On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> 
> I think we'll need to think out what we want for:
>  - the new set of flags
>  - the new output format for info/search
>  - if any other changes needed: e.g. split 'apk version' to two or
>    three applets
>  - then break things in one go and do apk-tools 2.5 or 3.0

Right, that makes perfect sense too.


On Fri, Jun 28, 2013 at 11:13:33AM +0200, Natanael Copa wrote:
> >  static struct apk_applet apk_add = {
> >  	.name = "add",
> > -	.help = "Add/update PACKAGEs to main dependencies and install them",
> > +	.help = "Add PACKAGEs to main dependencies and install (or upgrade) "
> > +		"them, while ensuring that all dependencies are met",
> >  	.arguments = "PACKAGE...",
> >  	.open_flags = APK_OPENF_WRITE,
> >  	.context_size = sizeof(struct add_ctx),
> 
> it could have been: (or upgrade, if -u is given)

How about this comment message for "apk add": "Register package in
'world' and install it, if necessary, while ensuring that all
dependencies are met"

Perhaps adding, either there or on the help for the "-u" flag, something
like "If the package is already installed, `apk add` ignores any updates
that may be available, unless the `-u` option is provided"


On Fri, Jun 28, 2013 at 11:19:03AM +0200, Natanael Copa wrote:
> > @@ -183,8 +183,8 @@ static int ver_main(void *pctx, struct apk_database *db, struct apk_string_array
> >  
> >  static struct apk_option ver_options[] = {
> >  	{ 'I', "indexes",	"Print description and versions of indexes" },
> > -	{ 't', "test",		"Compare two given versions" },
> > -	{ 'c', "check", 	"Check if the given version string is valid" },
> > +	{ 't', "test",		"Compare two given versions, output '<' '=' or '>'" },
> > +	{ 'c', "check", 	"Check the given version strings, output any that are invalid" },
> >  	{ 'a', "all",		"Consider packages from all repository tags" },
> >  	{ 'l', "limit",		"Limit output to packages with status matching one of LIMCHARs",
> >  	  required_argument, "LIMCHARs" },
> 
> shouldn't it be a comma (,) in there?
> 
> ...output '<', '=' or '>'

If you like. I'll have a look to see whether this is a commit you want
me to re-supply.


> > @@ -192,7 +192,8 @@ static struct apk_option ver_options[] = {
> >  
> >  static struct apk_applet apk_ver = {
> >  	.name = "version",
> > -	.help = "Compare package versions",
> > +	.help = "Compare package versions (in installed database vs. available) "
> > +		"or do tests on literal version strings (with or without -rN suffixes)",
> >  	.open_flags = APK_OPENF_READ,
> >  	.context_size = sizeof(struct ver_ctx),
> >  	.num_options = ARRAY_SIZE(ver_options),
> 
> Can we drop the "(with or without -rN suffixes)" part? it looks like -r -N options...

If you like. Is there some other way we might communicate the same
thing? Otherwise there's no way for someone to figure this out except by
experimenting. Which isn't sooo bad.


On Fri, Jun 28, 2013 at 11:31:01AM +0200, Natanael Copa wrote:

> >  	if (apk_flags & APK_SIMULATE) {
> > -		apk_warning("This simulation is not reliable as apk-tools upgrade is available.");
> > +		apk_warning("This simulation is not reliable if apk-tools upgrade is available.");
> >  		goto ret;
> >  	}
> >  
> 
> I think this warning will/should only be displayed when it would
> perform a self-upgrade. Proper warning would probably be:
> 
> "This simulation is not reliable as apk-tools or its dependencies would be upgraded".

On Fri, Jun 28, 2013 at 01:55:54PM +0300, Timo Teras wrote:
> On Fri, 28 Jun 2013 11:31:01 +0200
> Natanael Copa <ncopa@alpinelinux.org> wrote:
> 
> > I think there have been bugs recently that has made apk perform the
> > self upgrade at 'random'. The self-upgrade should only happen when
> > apk-tools or one of its dependencies are upgraded. Maybe it should
> > self-upgrade only when apk-tools itself needs upgrade. (dependencies
> > should be ABI compat so they should not have any effect on the result)
> 
> Yes, the new solver code is better at this. There is still situations
> when dependencies need to get upgraded. E.g. new apk-tools depends on
> libc>=something. And that needs libc upgrade to get satisfied.

Right, the version I was originally developing these patches against
would always give the warning, that's why I reworded it. I hadn't
noticed that the logic had now changed.

I like the idea that Natanael and Timo were discussing of just using
installed dependencies when self-upgrading---if the ABIs permit.


On Fri, Jun 28, 2013 at 01:03:19PM +0300, Timo Teras wrote:
> On Fri, 28 Jun 2013 11:35:09 +0200
> Natanael Copa <ncopa@alpinelinux.org> wrote:
> 
> > On Thu, 27 Jun 2013 15:28:51 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> > 
> > > ---
> > >  src/add.c     | 4 ++++
> > >  src/apk.c     | 4 ----
> > >  src/dot.c     | 4 ++++
> > >  src/fetch.c   | 4 ++++
> > >  src/fix.c     | 4 ++++
> > >  src/info.c    | 4 ++++
> > >  src/search.c  | 4 ++++
> > >  src/upgrade.c | 4 ++++
> > >  src/ver.c     | 4 ++++
> > >  9 files changed, 32 insertions(+), 4 deletions(-)
> > 
> > Since there are many applets using same option, I wonder if we could
> > join them somehow?
> > 
> > It might not matter since I think the gcc optimizer will store only
> > one copy of the identical string constants.
> 
> I think it should do this automatically. But I really don't like
> duplicating the code how to handle each option in all the applets.
> 
> I do like the idea of pushing these options down the applets that
> actually use them. So seems we need some sort of "option group" support.

I understand where you're coming from. Pragmatically, though, the
option-handling code is just a single bit-setting in each case.
Replacing this with a duplicate bit-setting to indicate the "option
group" doesn't seem to gain much.

On the other hand, maybe there are broader benefits to introducing
option groups. Also, it's true that there is the duplicated usage
message.


On Fri, Jun 28, 2013 at 03:46:31PM +0200, Natanael Copa wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> > Here are some further ideas for changes that I DON'T try to implement here, but
> > I submit for consideration/discussion.
> > ...
> > * As with "apk index" -> "apk mkindex", I'd find it easier if we aliased "apk
> >   update" to something less similar to "apk upgrade": perhaps "apk pull"?
> 
> apk pull reminds me of git pull. (which will do both fetch and merge),
> but is an option yes.
> 
> other options:
>   apk (re)fresh
>   apk fetchdb
>   apk syncdb
> 
> I'm not convinced it is worth it though.
> 
> maybe a single 'apk -U'?

Right, "git pull" was the model for my suggestion. "git fetch" is the
closer analogy, but "apk fetch" is already used.

I like the idea of honoring bare "apk -U/--update-cache" the best. I
think implementing that would require somewhat more ambitious code
changes.


On Fri, Jun 28, 2013 at 02:08:09PM +0300, Timo Teras wrote:
> On Thu, 27 Jun 2013 15:28:52 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > Also add infrastructure for short-option-only synonyms
> 
> Care to split the infrastructure to separate commit?
> 
> I'm willing to commit that, along with the "search -x" alias and
> reordering of the options where needed, before tagging 2.4.0.
> 
> The -R / -D options thingy, along with version, index, search and info
> applet changes will be postponed.
> 
> I pushed the first four commits already with ncopa's Ack. I did minor
> change as suggested by ncopa to one of the commits, and reworded the
> commit message.
> 
> Please reword the commit messages similarly if resending the above
> mentioned commits.

Ok, will do this shortly.


On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > * I'm not sure how things stand with the current version of
> > apk-tools. But I know that at least with 2.3.4ish versions, "apk fix"
> > would ignore /etc/apk/cache. That is, if I have foo-1.0 in the cache,
> > but foo-1.1 is available on the repositories, then even if I
> > explicitly request "apk fix -r foo" (as opposed to "apk fix -u foo"),
> > I'd get upgraded to foo-1.1. This is surprising and undesirable.
> > Could we change solver.c to prefer packages in /etc/apk/cache in such
> > cases?
> 
> This should have been fixed with the new solver code.

Great!


On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > * It'd be nice if "apk version" also displayed which repository an
> > upgrade would come from.
> 
> It shows the pinning. For the exact repositories, one can now use "apk
> policy <pkgname>". Do note that "apk version" says the latest version,
> not the version it would upgrade to.

Wow, I didn't realize that at all.

> Apk version is a wee bet overloaded, as it can do many unrelated
> things. Might be time to split it.

I agree. Should some of this functionality be merged with the new policy
applet? Haven't yet sorted that out in my mental map.


On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > * Is "--overlay-from-stdin" really a generic option, or like
> > --clean-protected and --purge does this option too only apply to some
> > of the applets?
> 
> It applies like --clean-protected. Applets that commit things to
> database use it. In practice it is only used on tmpfs root setups
> during initramfs bootstrap.

Ok, then should it also be pushed down into the applets that use it? Or the
appropriate "option group"?


On Fri, Jun 28, 2013 at 02:36:45PM +0200, Natanael Copa wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
>  
> > 1. One set of changes is that we move some options that are now listed in the
> > "generic options" usage block, but which don't in fact apply to all applets,
> > into the applet-specific option set for the applets that use them. This applies
> > to -U/--update-cache, --purge, and --clean-protected.
> 
> I think this is good. I am not 100% sure but I think that the short form id integer
> might need to be universally unique.

Is that right? They can't even be duplicated between applets? I think
there is some such duplication already in the code base. But this is
just going by distant memory.


On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > * One of the patches below deprecates short-form "apk info -i", for
> > reasons described in the commit. Now, the following proposal is
> > probably just my own taste. But I'd suggest deprecating a bunch more
> > of the short-form options:
> 
> Agreed, these could do a little rework. Most of apk flags are what
> they are due to historical reasons (from the shell based apk-tools
> 1.x), and the rest just "evolved" when needed.
> 
> Redesigning the current set of flags to be "unified" would be a good
> thing.

Again, this was just to start discussion. But I'm glad our
general inclinations here are in line.


On Fri, Jun 28, 2013 at 03:46:31PM +0200, Natanael Copa wrote:
> 
> apk fetch -s is useful to list contents of an uninstalled package:
>   apk fetch --stdout pkg | tar -zt
> 
> ...
> 
> maybe change 'apk fetch -s' to 'apk fetch -O' similar to 'tar -O' (and
> 'wget -O -')

I wasn't suggesting to eliminate the functionality, just the short-form
option name "-s". I like the "-O" short-form much better.


On Fri, Jun 28, 2013 at 02:36:45PM +0200, Natanael Copa wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
>
> > For the most part, these UI tweaks don't introduce anything that will break
> > existing behavior---except in 1 place (or perhaps 1-and-a-half places), which
> > I'll describe below...
> 
> I am a bit sceptic to this kind of changes. It basically means that
> there are some things that simply cannot be used in scripts...

I understand. I was trying very hard to minimize the breakage. The -R/-D
stuff needs more discussion. The "-and-a-half" thing I was referring to
above was about "apk info -i", but that seems to be currently broken
anyway (also the long form).

I was thinking we should make sure the public scripts use long-form
options (I've verified that many of them already do, except for a bunch of uses
of -q). I was thinking also that where possible, changes be introduced
like this:

        * first the new applet name/option name is enabled, and the
          old names are still honored, but the usage message suggests to
          use the new forms.
        * a bit later, the old forms are no longer listed in the usage
          message, but they are still honored, except that we also
          at the same time emit a message to stderr.

This won't break anything that doesn't capture stderr.

Also when I suggest "eliminating" short option-names, I just
mean easing them out of the recommended usage and so
on, as above, but---where possible---still honoring them.

It's just in a few places that things really invite being cleaned up in
a way that requires more breakage. The "apk info -R" is the dominant
example. I wholly agree this needs more discussion and
thought.

> ... unless we
> provide a simple way for a script to fish out the apk scripting "api"
> version.
> 
> Maybe introduce apk --api-version
> 
> if empty, then its current api, then whenever we change the scripting
> 'api' or output format, we bump the "api-version" number.
> 
> That way scripts has a way to deal with this kind of changes in future.
> like:
> 
> apk_api="$(apk --api-version 2>/dev/null)"
> : ${apk_api:=0}
> 
> if [ $apk_api -le 1 ]; then
> 	apk_mkindex="apk index";;
> else
> 	apk_mkindex="apk mkindex";;
> fi
> 
> $apk_mkindex *.apk .... etc

That's heavy-handed. Maybe it might be called for in the end, but I
hope we can find some lighter-weight and elegant solution. What I
described above wouldn't introduce any breakage with respect to "apk
index"; we'd just eventually not be documenting its existence, but would
continue to honor it.


On Thu, 27 Jun 2013 15:28:45 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> * "apk info" and "apk search" have different output styles, and
> interact with "-q" and "-v" differently. Here is the current behavior:
> 
>     apk info:     list all installed packages, without -1.0-r0
> suffixes apk info -v:  list all installed packages, with -1.0-r0
> suffixes apk info -vv: list all installed packages, with -1.0-r0
> suffixes, also list descriptions
>     apk info -v [moreoptions] packagename: machine-friendly output
> 
>     apk search substring:    list matching packages, with 1.0-r0
> suffixes apk search -q substring: suppress -1.0-r0 suffixes
>     apk search -v substring: list matching packages plus
> descriptions, on one line
> 
>   I observe also that "apk info" always seems to ignore "-q", and
> "apk version -q" is, perversely, much more verbose than "apk version".
>   
>   This is all confusing and hard to remember. It'd be nice if we could
>   standardize on a single mapping between output formats and options,
> perhaps following the pattern of "apk search".


On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> 
> It might be also possible now to merge 'search' and 'info' applets
> together. The fundamental difference is that info works with installed
> packages, and search works with available packages - thus info does
> have some extra information output that is available only with
> installed packages. But all in all, most of the functionality is shared.

Maybe. The main conflicts I can think of are with bare "apk info" vs
bare "apk search", and with "apk info --rdepends" vs "apk search
--rdepends". Also "apk info ..." requires an exact package name, right?
whereas "apk search ..." defaults to accepting a glob pattern.

I don't mind having the separate applets.


On Fri, Jun 28, 2013 at 03:46:31PM +0200, Natanael Copa wrote:
> 
> How about we introduce 'apk list' or 'apk ls' to list installed packages?

That's a possibility. (Replacing bare "apk info".)

> 'apk info -s' for size, like 'du -s'

That makes sense. I do value the existence of such patterns.


> Yeah, apk info output format have annoyed me too, specially the -q
> thingy since it makes it hard to use in scripts.
> 
> How about we introduce 'apk list' or 'apk ls' to list installed packages?
> 
> apk ls:		list installed packages, with 1.0-r0 suffixes
> apk ls -q:	list installed packages, without 1.0-r0 suffixes
> apk ls -v:	list installed packages, with description
> apk ls GLOB...:	list installed package which fnmatches GLOB(s)
> 
> Me and Timo as talked about a 'world' applet but a --world option could
> solve that.
> 
> apk ls --world:	list world
> 
> Then 'apk info' would be more a tool to give information about
> specified packages.
> 
> I am also missing: 'apk info --origin' to print the aport it comes from.
> 
> Maybe we could introduce 'apk info --format FORMAT' where format could
> have % modifiers that corresponds to the field in installed db:
> 
>  %C  checksum
>  %P  package name
>  %V  version
>  %A  arch
>  %S  package size (apk)
>  %I  installed size
>  %T  description text
>  %U  homepage
>  %L  license
>  %o  origin (aport name)
>  %m  package maintainer
>  %t  timestamp
>  etc...
> 
> that way you could sort installed packages by size:
> 
>   apk info --format "%I %P" '*' | sort -n

All of these are welcome ideas, from my side.


On Fri, Jun 28, 2013 at 04:03:54PM +0200, Natanael Copa wrote:
> On Fri, 28 Jun 2013 13:35:31 +0300
> Timo Teras <timo.teras@iki.fi> wrote:
> 
> > > diff --git a/src/apk.c b/src/apk.c
> > > index c3709e7..4bac0ba 100644
> > > --- a/src/apk.c
> > > +++ b/src/apk.c
> > > @@ -46,6 +46,7 @@ static struct apk_option generic_options[] = {
> > >  				required_argument, "DIR" },
> > >  	{ 'X', "repository",	"Use packages from REPO",
> > >  				required_argument, "REPO" },
> > > +	{ 0x113, "no-log",      "Don't write to log" },
> > >  	{ 0x101, "progress",	"Show a progress bar" },
> > >  	{ 0x10f, "progress-fd",	"Write progress to fd",
> > 
> > This might have non-wanted implications on the tmpfs initramfs
> > bootstrap.
> > 
> > I've been thinking that we need some flag for apk to indicate that it's
> > the tmpfs initial initramfs call to get proper defaults for flags like
> > these.
> 
> I am generally against apk trying to be smart but one option is to
> check if --root is specified and if destination directory is a tmpfs.
> 
> maybe add a --bootstrap option which would correspond to:
>  --overlay-from-stdin
>  --no-network
>  --clean-protected
>  --initdb
> 
> I suppose the challenge here is that many of the options are
> conditional. For example, if there are no apkovl, there should be no
> --overlay-from-stdin (an be worked around with /dev/null tricks) and if
> there are PXE network repos we replace the --no-network with
> --update-cache.
> 
> The --clean-protected is currently also optional with the boot option "keep_apk_new"

No comment here from me, I just wanted to extract and propagate this
part of the discussion.


-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 06/15] move -U option to applets that use it

Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20130628130319.3926fe1c@vostro>
In-Reply-To
<20130628113509.136ebe3c@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1372413799
DKIM signature
missing
Download raw message
On Fri, 28 Jun 2013 11:35:09 +0200
Natanael Copa <ncopa@alpinelinux.org> wrote:

> On Thu, 27 Jun 2013 15:28:51 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > ---
> >  src/add.c     | 4 ++++
> >  src/apk.c     | 4 ----
> >  src/dot.c     | 4 ++++
> >  src/fetch.c   | 4 ++++
> >  src/fix.c     | 4 ++++
> >  src/info.c    | 4 ++++
> >  src/search.c  | 4 ++++
> >  src/upgrade.c | 4 ++++
> >  src/ver.c     | 4 ++++
> >  9 files changed, 32 insertions(+), 4 deletions(-)
> 
> Since there are many applets using same option, I wonder if we could
> join them somehow?
> 
> It might not matter since I think the gcc optimizer will store only
> one copy of the identical string constants.

I think it should do this automatically. But I really don't like
duplicating the code how to handle each option in all the applets.

I do like the idea of pushing these options down the applets that
actually use them. So seems we need some sort of "option group" support.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] futher apk ideas

Details
Message ID
<20130628171945.GD1712@zen.nyu.edu>
In-Reply-To
<20130628163747.GB1712@zen.nyu.edu> (view parent)
Sender timestamp
1372439985
DKIM signature
missing
Download raw message
Some follow-up about -R/-D.

On Fri, Jun 28, 2013 at 02:36:45PM +0200, Natanael Copa wrote:
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
>
> > So the strongest existing pattern here seems to be to use "-R" to mean
> > "recurse".
> 
> Keep in mind that in apk context, there are 3 different
> kinds of "recurse":
>  * recurse filedirectories:
>      apk audit --recursive
> 
>  * recurse dependencies downward/forward/by depends:
>      apk fetch --recursive
> 
>  * recurse reverse dependencies (upward/backward/by required-by):
>      apk del --rdepends

Right. Currently I have -R/--recursive in "apk audit" and "apk fetch"
and -R/--rdepends in "apk del". Not thinking about breakage for the
moment, maybe the "apk fetch" option should just be -D/--depends, and
always be recursive when supplied.

> 
> What if you want list 'depends' without recursing? (apk info <show the depends>)

Right, I agree it should be possible to do both. I was thinking maybe
"apk info -D" for all the depends, recursively, and "apk info -D -1" for
just a single level. But maybe it'd be better to have "apk info -D" just
do the single level (as it does now), and "apk info -D --recursive" do
the recursing. And maybe it'd be better to use "-R" as the short-form
for "--recursive".

Instead of -R/--rdepends, then, we'd need something like --N/--needers.
But perhaps we can find a better name.

> What if you only want know the direct related package upwards (think
> when an abi change for a library and you want to know what packages
> needs to be rebuilt)
> 
> how about --recurse-rdepends?

Right, we could have --needers (substitute better option name here) do a
single level, and --needers --recursive go recursively upwards.


> Here is a summary of all options that are recursive:
> 
> Options for del command:
>   -r, --rdepends          Recursively delete all top-level reverse dependencies
>                           too
> Options for fix command:
>   -d, --depends           Fix all dependencies too
> 
> Options for fetch command:
>   -R, --recursive         Fetch the PACKAGE and all its dependencies
> 
> Options for audit command:
>   -r, --recursive         List individually all entries in new directories
> 
> 
> Here are relevant --depends/--rdepends options that are non-recursive:
> 
> Options for info command:
>   -R, --depends           List packages that the PACKAGE depends on
>   -r, --rdepends          List all packages depending on PACKAGE
> 
> Options for search command:
>   -r, --rdepends          Print reverse dependencies of package
> 
> Note that for some commands only one direction of recurive dependencies
> makes sense.
> apk fetch - makes no sense with --recurse-rdepends
> apk del - makes no sense with --recurse-depends

Right.

> I think recursive operation makes no sense for apk info, but for apk
> search, yes.

No, I've several times had to hand-script recursive operations for "apk
info". If you're just going downwards, then you could use apk search
too; but you might want to go recursively upwards, limited just to
installed packages.

> When i think of it, --recursive only make sense downwards in dependency
> tree (similar when talking about directories in file system) with the
> exception of 'apk del'

As I said, I can remember needing this several times over the past
months. Don't remember the details though; or anyway, can't remember
them in a form where I can easily abstract away the idiosyncracies of
what I happened to be doing.


> The above summary would be change to (* means a breakage from current):
> Options for del command:
>   -r, --rdepends          Recursively delete all top-level reverse dependencies
>                           too
> Options for fix command:
> * -R, --recursive         Recursively fix all dependencies too
> 
> Options for fetch command:
>   -R, --recursive         Recursively fetch the PACKAGE and all its dependencies
> 
> Options for audit command:
> * -R, --recursive         Recursively list individually all entries in new directories
> 
> 
> Since -R now means 'recursive' and -d already means 'description' we
> could change apk info's non recursive to -D
> 
> Options for info command:
> * -D, --depends           List packages that the PACKAGE depends on
> 
> But i am also ok with keeping 'apk info -R' as an exception. (i think
> -R was originally taken to correspond to BSD's pkg_info -R)
> 
> how does that sound?


How about this:


Options for del command:
  -N, --needed            Recursively delete all top-level reverse dependencies too
  -r                      Synonym for -N (deprecated)

No option is needed here to recursively delete all downward dependencies
that aren't required by anything in 'world', right? Because we are
always going to do that by design.


Options for fix command:
  -R, --recursive         Recursively fix all dependencies too
  -d                      Synonym for -R (deprecated)
  -r, --reinstall         Reinstall the package (default) <--- would
prefer not to have "apk del -r" be canonical, to avoid confusion with
other uses of "-r" like this


Options for fetch command:
  -R, --recursive         Recursively fetch the PACKAGE and all its dependencies


Options for audit command:
  -R, --recursive         Recursively list individually all entries in new directories
  -r                      Synonym for -R (deprecated) <-- as with "apk
fix -r"


Options for info command: (or "apk info --world", if we go that route)
  -d, --description       Print description for PACKAGE
  -D, --depends           List packages that the PACKAGE (directly) depends on
  -R                      Synonym for -D (deprecated)
  -N, --needed            List all installed packages (directly) depending on PACKAGE
  -r                      Synonym for -N (deprecated)

Except we might introduce breakage here and have -R combine with -D and
-N to make them recursive.


Options for search command: (or "apk info" without "--world", if we go
that route)
  -d, --description       Search package descriptions (implies -a)
  -N, --needed            List all (installed and uninstalled) packages (directly) depending on PACKAGE
  -r                      Synonym for -N (deprecated)
  -R                      Combines with -N to make it recursive


Again, I'm not especially fond of the particular choice -N/--needed.
Just using it because I don't have something better.

-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20130628132145.52918d9d@vostro>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372414905
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:45 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> Some months ago, I patched apk-tools in various ways to (in my view)
> improve the UI and also to provide a logging mechanism. I've been
> using these in practice on my local machine. It's about time to
> rebase them against the current apk-tools git repo, and see if they
> can be incorporated upstream.
> 
> This set of patches has the UI tweaks. It'll take me a bit longer to
> rebase/test the logging patch against the current apk-tools
> sourcebase.
> 
> For the most part, these UI tweaks don't introduce anything that will
> break existing behavior---except in 1 place (or perhaps 1-and-a-half
> places), which I'll describe below. However, I have introduced some
> new short/long option flags for existing functionality, and in some
> places have declared the old flags "deprecated." In the current
> implementation, all that deprecation amounts to is that the usage
> message recommends the new flag; no warnings are output when the old
> flag is in fact used.
> 
> 1. One set of changes is that we move some options that are now
> listed in the "generic options" usage block, but which don't in fact
> apply to all applets, into the applet-specific option set for the
> applets that use them. This applies to -U/--update-cache, --purge,
> and --clean-protected.

Correct. These basically apply to applets that eventually commit
changes to database.

But as mentioned I'd rather have these as an option group. And keep the
help text in single place along with the code to handle these options.
Either have a "option_groups" bitfield and implement these in the
general code, or add some functions to "install" or "register" these
shared extra options per-applet.

> 2. A second change we introduce is that we accept "apk mkindex" to
> mean what "apk index" already means, and prefer the former. This
> makes its behavior more memorable,at least for me, and stops me from
> wondering why functions like "apk version -l" aren't underneath the
> "apk index" applet instead.

Sound reasonable.

> A lot of changes try to impose some more consistency on the option
> flags, especially the short option flags, either with other applets
> or with familiar POSIX utilities.
> 
> 3. One of those sets of changes concerns the various flags for
> recursing upwards or downwards in the dependency tree.
> 
> Let me frame my overview of those changes with this observation:
> POSIX tools mostly use -R for recursive operations (consider chmod,
> chown, chgrp, ls, cp, rm). cp also accepts -r, sometimes with
> equivalent behavior to -R. But not all implementations can be relied
> on to treat "cp -R" and "cp -r" equivalently; and where they diverge,
> it's usually the first that's wanted. (See the OS X cp.1 manpage.) rm
> also accepts -r, and can be relied on to treat "rm -R" and "rm -r"
> equivalently. But the IEEE/Open Group's rm.1p manpage recommends
> using "rm -R", for consistency with other utilities. The Gnu *grep
> utilities (which are also the defaults on some BSD systems) also
> treat -R and -r equivalently. As it happens, BusyBox *grep only
> honors -r, but I will be submitting a patch to BusyBox upstream to
> also accept -R, as the Gnu versions do.
> 
> The only remaining familiar utilities to ONLY accept -r for recursive
> functionality are diff and rsync. On the other hand, a whole range of
> utilities use -r for other purposes (consider date, touch, ls, sort,
> Gnu and BusyBox sed, xargs, vi, and so on).
> 
> So the strongest existing pattern here seems to be to use "-R" to mean
> "recurse".
> 
> But what does a recursive operation in a dependency tree amount to?
> We could mean "also operate on the specified package's dependencies."
> Let's use --depends as the long-form name of that option. (As
> apk-tools sometimes does; currently it also sometimes uses
> --recursive here instead.) Or we could mean "also operate on the
> packages that depend on the specified package." Let's use --rdepends
> as the long-form name of that option. (For "reverse-depends", not
> "recursive depends.") It would be confusing to have -R be the
> short-form option for "--depends", and some other letter be the
> short-form option for "--rdepends". So I propose we consistently use
> "-R" in the apk-tools namespace to mean "--rdepends", that is, to
> operate recursively UPWARDS in the dependency graph (towards packages
> that have more dependencies). Sometimes apk-tools currently uses "-d"
> as the short-form option for the other direction (--depends). But
> other times apk-tools uses -d differently. For consistency with -R, I
> propose we use "-D" here instead.
> 
> So in general:
> 
>   -D/--depends means to also apply an operation to the packages that
> the specified package depends on, that is, downwards in the dependency
>   graph
> 
>   -R/--rdepends means to also apply an operation to the packages that
>   depend on the specified package, that is, upwards in the dependency
>   graph

Merging these flags has been something I've been thinking as well. I
definitely agree that they need a redo. See below for more.

> These patches roll out that change across the apk applets and usage
> messages, while still accepting the old short and long options too,
> where these exist. We just declare some of the old options as
> "deprecated" in the usage messages.
> 
> There's only one place where this requires us to introduce a breaking
> change: currently "apk info -R" is interpreted as "apk info
> --depends", but these changes will make it be interpreted in the
> other direction, as "apk info --rdepends". I hope this small
> deviation from existing behavior is tolerable.
> 
> One awkwardness I haven't resolved is that in most cases, both the -D
> and -R options are recursive: -D operates on your dependencies, and
> their dependencies, and so on. However in "apk info", I think -D and
> -R only apply to a single level of dependencies: only your direct
> dependencies, and so on. It'd be nice if we could make this work
> recursively too (and perhaps had a flag to limit the recursion to
> only a single level). But that isn't implemented here.
> 
> 
> 4. Another option-related change is that we now let "apk search -x"
> mean "apk search -e/--exact", and prefer the former. This is
> consistent with the -x flag on grep, and also steps away from the
> conflicting meaning of "-e" in "apk info".

Sounds ok.

> There are some other changes as well, which should be noted in the
> individual commits. Here I'm just trying to give the high-level
> overview, not an exhaustive description.
> 
> Here are some further ideas for changes that I DON'T try to implement
> here, but I submit for consideration/discussion.
> 
> * As with "apk index" -> "apk mkindex", I'd find it easier if we
> aliased "apk update" to something less similar to "apk upgrade":
> perhaps "apk pull"?

Not so sure about this one. Then again, "-U" flag in the applets where
it takes effect, does what 'update' does alone. Need to think this a
bit.

> * I'm not sure how things stand with the current version of
> apk-tools. But I know that at least with 2.3.4ish versions, "apk fix"
> would ignore /etc/apk/cache. That is, if I have foo-1.0 in the cache,
> but foo-1.1 is available on the repositories, then even if I
> explicitly request "apk fix -r foo" (as opposed to "apk fix -u foo"),
> I'd get upgraded to foo-1.1. This is surprising and undesirable.
> Could we change solver.c to prefer packages in /etc/apk/cache in such
> cases?

This should have been fixed with the new solver code.

> * It'd be nice if "apk version" also displayed which repository an
> upgrade would come from.

It shows the pinning. For the exact repositories, one can now use "apk
policy <pkgname>". Do note that "apk version" says the latest version,
not the version it would upgrade to.

Apk version is a wee bet overloaded, as it can do many unrelated
things. Might be time to split it.

> * for backwards compatibility, "apk fetch -R" is still honored,
> though "apk fetch -D" is now the preferred form. It may be confusing
> to have "apk fetch -D" and "apk fetch -R" have the same
> functionality, so we could consider immediately deprecating "apk
> fetch -R" more forcefully, for example by issuing a warning message.
> 
> * As I mentioned above, it'd be nice if "apk info -D/-R" recursed
> over more than a single level of dependencies, or at least if there
> were an option to do so.
> 
> * Is "--overlay-from-stdin" really a generic option, or like
> --clean-protected and --purge does this option too only apply to some
> of the applets?

It applies like --clean-protected. Applets that commit things to
database use it. In practice it is only used on tmpfs root setups
during initramfs bootstrap.

> * One of the patches below deprecates short-form "apk info -i", for
> reasons described in the commit. Now, the following proposal is
> probably just my own taste. But I'd suggest deprecating a bunch more
> of the short-form options: "apk -p", "apk fetch -s", "apk index -x",
> "apk upgrade -a", and all of "apk info -IPswt". In the first two
> cases, because these are unusual actions anyway and the short-form
> options aren't very memorable. It's easier and clearer in practice to
> just use the long form; and then the apk-tools option namespace will
> be clearer. In the third case ("apk index -x"), in part because this
> conflicts with the different meaning introduced above for "-x" wth
> "apk search." In part also because there's the confusing variety of
> "apk -X/--repository", "apk version -I/--indices", "apk index
> -x/--index". In the fourth case ("apk upgrade -a"), because it
> conflicts with the different meaning for "-a" ("--all") in some other
> apk commands. In the case of the "apk info" options: -I already has a
> different meaning for "apk version", plus I already suggested not
> using its relative "-i". Additionally, "-I" and "-P" are different in
> the character of their behavior from other capital letter short-form
> options for "apk info" (-L, -W, -R, -D). It seems clearer to just use
> the long forms for "-I" and "-P"; plus these are going to be rare
> actions in any case. For "apk info -swt": it's hard to remember which
> output-selecting options have short-forms (and what they are) and
> which don't. It'd be cleanest to just honor "-d" for "--description"
> and have the other output options be long-form only. Also, "-s" for
> "apk info" would conflict with the meaning of "-s" for "apk fetch",
> if we chose to retain that.

Agreed, these could do a little rework. Most of apk flags are what
they are due to historical reasons (from the shell based apk-tools
1.x), and the rest just "evolved" when needed.

Redesigning the current set of flags to be "unified" would be a good
thing.

> * I don't think I understand the difference between "apk add foo" and
> "apk add -u/--upgrade foo". Perhaps I asked about this before, but if
> it was ever explained to me, it's not something I've kept track of.

apk add always adds the given files to 'world'. If foo is already
installed, it is not upgraded by default (unless dependencies so
required).

Thus, if foo is installed: apk add -u foo, will upgrade it; apk add foo
will not but just ensures it is in world so that future apk del
pkg-using-foo will not cause it to be deleted due to
becoming unneeded dependency.

> * "apk info" and "apk search" have different output styles, and
> interact with "-q" and "-v" differently. Here is the current behavior:
> 
>     apk info:     list all installed packages, without -1.0-r0
> suffixes apk info -v:  list all installed packages, with -1.0-r0
> suffixes apk info -vv: list all installed packages, with -1.0-r0
> suffixes, also list descriptions
>     apk info -v [moreoptions] packagename: machine-friendly output
> 
>     apk search substring:    list matching packages, with 1.0-r0
> suffixes apk search -q substring: suppress -1.0-r0 suffixes
>     apk search -v substring: list matching packages plus
> descriptions, on one line
> 
>   I observe also that "apk info" always seems to ignore "-q", and
> "apk version -q" is, perversely, much more verbose than "apk version".
>   
>   This is all confusing and hard to remember. It'd be nice if we could
>   standardize on a single mapping between output formats and options,
> perhaps following the pattern of "apk search".

It might be also possible now to merge 'search' and 'info' applets
together. The fundamental difference is that info works with installed
packages, and search works with available packages - thus info does
have some extra information output that is available only with
installed packages. But all in all, most of the functionality is shared.

I think we'll need to think out what we want for:
 - the new set of flags
 - the new output format for info/search
 - if any other changes needed: e.g. split 'apk version' to two or
   three applets
 - then break things in one go and do apk-tools 2.5 or 3.0

I will likely commit the minor clean ups to master before next tag. But
the bulk of this, and the logging patch set would likely wait for 3.0.

The reason is we're planning to backport apk-tools 2.4.x to our -stable
alpine releases and do not want to break things there.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 05/15] reword upgrade messages

Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20130628135554.1a20f14e@vostro>
In-Reply-To
<20130628113101.0e552bd3@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1372416954
DKIM signature
missing
Download raw message
On Fri, 28 Jun 2013 11:31:01 +0200
Natanael Copa <ncopa@alpinelinux.org> wrote:

> On Thu, 27 Jun 2013 15:28:50 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> I think there have been bugs recently that has made apk perform the
> self upgrade at 'random'. The self-upgrade should only happen when
> apk-tools or one of its dependencies are upgraded. Maybe it should
> self-upgrade only when apk-tools itself needs upgrade. (dependencies
> should be ABI compat so they should not have any effect on the result)

Yes, the new solver code is better at this. There is still situations
when dependencies need to get upgraded. E.g. new apk-tools depends on
libc>=something. And that needs libc upgrade to get satisfied.

> >  src/upgrade.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/upgrade.c b/src/upgrade.c
> > index 9eb7890..0d7155a 100644
> > --- a/src/upgrade.c
> > +++ b/src/upgrade.c
> > @@ -64,7 +64,7 @@ int apk_do_self_upgrade(struct apk_database *db,
> > unsigned short solver_flags) goto ret;
> >  
> >  	if (apk_flags & APK_SIMULATE) {
> > -		apk_warning("This simulation is not reliable as
> > apk-tools upgrade is available.");
> > +		apk_warning("This simulation is not reliable if
> > apk-tools upgrade is available."); goto ret;
> >  	}
> >  
> 
> I think this warning will/should only be displayed when it would
> perform a self-upgrade. Proper warning would probably be:
> 
> "This simulation is not reliable as apk-tools or its dependencies
> would be upgraded".

Agreed.

> Or even better, make apk upgrade ignore when an apk-tools dependency
> is upgraded and only perform self-upgrade when apk-tools itself only
> is upgraded.

Not fully possible. It is possible to change that during self-upgrade
the installed versions of dependencies are preferred. This would in
practice mean:

--- a/src/upgrade.c
+++ b/src/upgrade.c
@@ -51,7 +51,7 @@ int apk_do_self_upgrade(struct apk_database *db, unsigned short solver_flags)
        int r;
 
        name = apk_db_get_name(db, APK_BLOB_STR("apk-tools"));
-       apk_solver_set_name_flags(name, solver_flags, solver_flags);
+       apk_solver_set_name_flags(name, solver_flags, 0);
        db->performing_self_update = 1;
 
        r = apk_solver_solve(db, 0, db->world, &changeset);


> > @@ -72,7 +72,7 @@ int apk_do_self_upgrade(struct apk_database *db,
> > unsigned short solver_flags) apk_solver_commit_changeset(db,
> > &changeset, db->world); apk_db_close(db);
> >  
> > -	apk_message("Continuing the upgrade transaction with new
> > apk-tools:");
> > +	apk_message("Continuing the upgrade transaction:");
> >  	for (r = 0; apk_argv[r] != NULL; r++)
> >  		;
> >  	apk_argv[r] = "--no-self-upgrade";


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 07/15] add -R and -D options

Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20130628140809.1283695d@vostro>
In-Reply-To
<f95d9046c93a25cc0521e3c6c8f01bef01a0a8f7.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372417689
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:52 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> Also add infrastructure for short-option-only synonyms

Care to split the infrastructure to separate commit?

I'm willing to commit that, along with the "search -x" alias and
reordering of the options where needed, before tagging 2.4.0.

The -R / -D options thingy, along with version, index, search and info
applet changes will be postponed.

I pushed the first four commits already with ncopa's Ack. I did minor
change as suggested by ncopa to one of the commits, and reworded the
commit message.

Please reword the commit messages similarly if resending the above
mentioned commits.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628143645.277c3eb5@ncopa-desktop.alpinelinux.org>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372423005
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:45 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> Some months ago, I patched apk-tools in various ways to (in my view) improve
> the UI and also to provide a logging mechanism. I've been using these in
> practice on my local machine. It's about time to rebase them against the
> current apk-tools git repo, and see if they can be incorporated upstream.
> 
> This set of patches has the UI tweaks. It'll take me a bit longer to
> rebase/test the logging patch against the current apk-tools sourcebase.
> 
> For the most part, these UI tweaks don't introduce anything that will break
> existing behavior---except in 1 place (or perhaps 1-and-a-half places), which
> I'll describe below. However, I have introduced some new short/long option
> flags for existing functionality, and in some places have declared the old
> flags "deprecated." In the current implementation, all that deprecation amounts
> to is that the usage message recommends the new flag; no warnings are output
> when the old flag is in fact used.

I am a bit sceptic to this kind of changes. It basically means that
there are some things that simply cannot be used in scripts, unless we
provide a simple way for a script to fish out the apk scripting "api"
version.

Maybe introduce apk --api-version

if empty, then its current api, then whenever we change the scripting
'api' or output format, we bump the "api-version" number.

That way scripts has a way to deal with this kind of changes in future.

like:

apk_api="$(apk --api-version 2>/dev/null)"
: ${apk_api:=0}

if [ $apk_api -le 1 ]; then
	apk_mkindex="apk index";;
else
	apk_mkindex="apk mkindex";;
fi

$apk_mkindex *.apk .... etc

 
> 1. One set of changes is that we move some options that are now listed in the
> "generic options" usage block, but which don't in fact apply to all applets,
> into the applet-specific option set for the applets that use them. This applies
> to -U/--update-cache, --purge, and --clean-protected.

I think this is good. I am not 100% sure but I think that the short form id integer
might need to be universally unique.
 
> 2. A second change we introduce is that we accept "apk mkindex" to mean what
> "apk index" already means, and prefer the former. This makes its behavior more
> memorable,at least for me, and stops me from wondering why functions like "apk
> version -l" aren't underneath the "apk index" applet instead.

I like this change. lets keep both for a while for backwards compat and
later we can remove 'apk index'.
 
> A lot of changes try to impose some more consistency on the option flags,
> especially the short option flags, either with other applets or with familiar
> POSIX utilities.

I like this.
 
> 3. One of those sets of changes concerns the various flags for recursing
> upwards or downwards in the dependency tree.
> 
> Let me frame my overview of those changes with this observation: POSIX tools
> mostly use -R for recursive operations (consider chmod, chown, chgrp, ls, cp,
> rm). cp also accepts -r, sometimes with equivalent behavior to -R. But not all
> implementations can be relied on to treat "cp -R" and "cp -r" equivalently; and
> where they diverge, it's usually the first that's wanted. (See the OS X cp.1
> manpage.) rm also accepts -r, and can be relied on to treat "rm -R" and "rm -r"
> equivalently. But the IEEE/Open Group's rm.1p manpage recommends using "rm -R",
> for consistency with other utilities. The Gnu *grep utilities (which are also
> the defaults on some BSD systems) also treat -R and -r equivalently. As it
> happens, BusyBox *grep only honors -r, but I will be submitting a patch to
> BusyBox upstream to also accept -R, as the Gnu versions do.
> 
> The only remaining familiar utilities to ONLY accept -r for recursive
> functionality are diff and rsync. On the other hand, a whole range of utilities
> use -r for other purposes (consider date, touch, ls, sort, Gnu and BusyBox sed,
> xargs, vi, and so on).
> 
> So the strongest existing pattern here seems to be to use "-R" to mean
> "recurse".

Keep in mind that in apk context, there are 3 different
kinds of "recurse":
 * recurse filedirectories:
     apk audit --recursive

 * recurse dependencies downward/forward/by depends:
     apk fetch --recursive

 * recurse reverse dependencies (upward/backward/by required-by):
     apk del --rdepends


> But what does a recursive operation in a dependency tree amount to? We could
> mean "also operate on the specified package's dependencies." Let's use
> --depends as the long-form name of that option. (As apk-tools sometimes does;
> currently it also sometimes uses --recursive here instead.)

What if you want list 'depends' without recursing? (apk info <show the depends>)

how about --recurse-depends?

> Or we could mean
> "also operate on the packages that depend on the specified package." Let's use
> --rdepends as the long-form name of that option. (For "reverse-depends", not
> "recursive depends.")

What if you only want know the direct related package upwards (think
when an abi change for a library and you want to know what packages
needs to be rebuilt)

how about --recurse-rdepends?

> It would be confusing to have -R be the short-form option
> for "--depends", and some other letter be the short-form option for
> "--rdepends". So I propose we consistently use "-R" in the apk-tools namespace
> to mean "--rdepends", that is, to operate recursively UPWARDS in the dependency
> graph (towards packages that have more dependencies). Sometimes apk-tools
> currently uses "-d" as the short-form option for the other direction
> (--depends). But other times apk-tools uses -d differently. For consistency
> with -R, I propose we use "-D" here instead.
> 
> So in general:
> 
>   -D/--depends means to also apply an operation to the packages that the
>   specified package depends on, that is, downwards in the dependency
>   graph
> 
>   -R/--rdepends means to also apply an operation to the packages that
>   depend on the specified package, that is, upwards in the dependency
>   graph

those 2 alone does not cover all cases.

Here is a summary of all options that are recursive:

Options for del command:
  -r, --rdepends          Recursively delete all top-level reverse dependencies
                          too
Options for fix command:
  -d, --depends           Fix all dependencies too

Options for fetch command:
  -R, --recursive         Fetch the PACKAGE and all its dependencies

Options for audit command:
  -r, --recursive         List individually all entries in new directories


Here are relevant --depends/--rdepends options that are non-recursive:

Options for info command:
  -R, --depends           List packages that the PACKAGE depends on
  -r, --rdepends          List all packages depending on PACKAGE

Options for search command:
  -r, --rdepends          Print reverse dependencies of package



Note that for some commands only one direction of recurive dependencies
makes sense.
apk fetch - makes no sense with --recurse-rdepends
apk del - makes no sense with --recurse-depends

I think recursive operation makes no sense for apk info, but for apk
search, yes.

When i think of it, --recursive only make sense downwards in dependency
tree (similar when talking about directories in file system) with the
exception of 'apk del', so basically we could do:

-R, --recursive forward depends when dealing with dependencies or
                filesystem (possibly with exception of apk info, which
                always it is non-recursive)

-r for "reverse dependency" (only apk del operates recursively on this,
   but it always operates "recursively")


The above summary would be change to (* means a breakage from current):
Options for del command:
  -r, --rdepends          Recursively delete all top-level reverse dependencies
                          too
Options for fix command:
* -R, --recursive         Recursively fix all dependencies too

Options for fetch command:
  -R, --recursive         Recursively fetch the PACKAGE and all its dependencies

Options for audit command:
* -R, --recursive         Recursively list individually all entries in new directories


Since -R now means 'recursive' and -d already means 'description' we
could change apk info's non recursive to -D

Options for info command:
* -D, --depends           List packages that the PACKAGE depends on

But i am also ok with keeping 'apk info -R' as an exception. (i think
-R was originally taken to correspond to BSD's pkg_info -R)


how does that sound?

> These patches roll out that change across the apk applets and usage messages,
> while still accepting the old short and long options too, where these exist. We
> just declare some of the old options as "deprecated" in the usage messages.
> 
> There's only one place where this requires us to introduce a breaking change:
> currently "apk info -R" is interpreted as "apk info --depends", but these
> changes will make it be interpreted in the other direction, as "apk info
> --rdepends". I hope this small deviation from existing behavior is tolerable.

I am sceptic to this because:
* it will break scripts
* the ouput is similar so it might be difficult to spot the change.
  (think a stressful situation, you log on to an old box via ssh, you
  do 'apk info -R' and need to make a fast desicion...)

> One awkwardness I haven't resolved is that in most cases, both the -D and -R
> options are recursive: -D operates on your dependencies, and their
> dependencies, and so on. However in "apk info", I think -D and -R only apply to
> a single level of dependencies: only your direct dependencies, and so on. It'd
> be nice if we could make this work recursively too (and perhaps had a flag to
> limit the recursion to only a single level). But that isn't implemented here.

I prefer -R mean recursive rather than -D. I don't like that -R goes
opposite what it means now.

> 4. Another option-related change is that we now let "apk search -x" mean "apk
> search -e/--exact", and prefer the former. This is consistent with the -x flag
> on grep, and also steps away from the conflicting meaning of "-e" in "apk
> info".

I'm ok with this. Makes sense.

> There are some other changes as well, which should be noted in the individual
> commits. Here I'm just trying to give the high-level overview, not an
> exhaustive description.
> 
> Here are some further ideas for changes that I DON'T try to implement here, but
> I submit for consideration/discussion.

I'll comment those in a separate email/thread.


-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 05/15] reword upgrade messages

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628144152.309b506d@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20130628135554.1a20f14e@vostro> (view parent)
Sender timestamp
1372423312
DKIM signature
missing
Download raw message
On Fri, 28 Jun 2013 13:55:54 +0300
Timo Teras <timo.teras@iki.fi> wrote:
 
> > Or even better, make apk upgrade ignore when an apk-tools dependency
> > is upgraded and only perform self-upgrade when apk-tools itself only
> > is upgraded.
> 
> Not fully possible. It is possible to change that during self-upgrade
> the installed versions of dependencies are preferred. This would in
> practice mean:
> 
> --- a/src/upgrade.c
> +++ b/src/upgrade.c
> @@ -51,7 +51,7 @@ int apk_do_self_upgrade(struct apk_database *db, unsigned short solver_flags)
>         int r;
>  
>         name = apk_db_get_name(db, APK_BLOB_STR("apk-tools"));
> -       apk_solver_set_name_flags(name, solver_flags, solver_flags);
> +       apk_solver_set_name_flags(name, solver_flags, 0);
>         db->performing_self_update = 1;
>  
>         r = apk_solver_solve(db, 0, db->world, &changeset);
> 
> 

I think this makes sense.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 09/15] Allow "apk search -x" for -e

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628144643.1d0d3dd6@ncopa-desktop.alpinelinux.org>
In-Reply-To
<64e093a929f8a2363bdc54e43ddf08ba9741b46a.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372423603
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:54 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> ---
>  src/search.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/search.c b/src/search.c
> index 122affe..4ef804d 100644
> --- a/src/search.c
> +++ b/src/search.c
> @@ -82,6 +82,7 @@ static int search_parse(void *ctx, struct apk_db_options *dbopts,
>  		ictx->show_all = 1;
>  		break;
>  	case 'e':
> +	case 'x':
>  		ictx->search_exact = 1;
>  		break;
>  	case 'o':
> @@ -171,7 +172,8 @@ static struct apk_option search_options[] = {
>  	{ 'U', "update-cache",	"Update the repository cache first" },
>  	{ 'a', "all",		"Show all package versions (instead of latest only)" },
>  	{ 'd', "description",	"Search package descriptions (implies -a)" },
> -	{ 'e', "exact",		"Require exact match (instead of substring match)" },
> +	{ 'x', "exact",		"Require exact match (instead of substring match)" },
> +	{ 'e', NULL,	        "Synonym for -x (deprecated)" },
>  	{ 'o', "origin",	"Print origin package name instead of the subpackage" },
>  	{ 'R', "rdepends",	"List all (installed and uninstalled) packages depending on PACKAGE" },
>  	{ 'r', NULL,	        "Synonym for -R (deprecated)" },

Ok, I am ok with this if its rebased to current git.


-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH 07/15] add -R and -D options

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628144942.53098c36@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20130628140809.1283695d@vostro> (view parent)
Sender timestamp
1372423782
DKIM signature
missing
Download raw message
On Fri, 28 Jun 2013 14:08:09 +0300
Timo Teras <timo.teras@iki.fi> wrote:

> On Thu, 27 Jun 2013 15:28:52 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > Also add infrastructure for short-option-only synonyms
> 
> Care to split the infrastructure to separate commit?
> 
> I'm willing to commit that, along with the "search -x" alias and
> reordering of the options where needed, before tagging 2.4.0.

Agree.

> The -R / -D options thingy, along with version, index, search and info
> applet changes will be postponed.

I don't like the invert functionality of -R.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] futher apk ideas (WAS: [PATCH 00/15] apk-tools UI fixes/refinements)

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130628154631.4d18107d@ncopa-desktop.alpinelinux.org>
In-Reply-To
<cover.1372361242.git.dubiousjim@gmail.com> (view parent)
Sender timestamp
1372427191
DKIM signature
missing
Download raw message
On Thu, 27 Jun 2013 15:28:45 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:
> Here are some further ideas for changes that I DON'T try to implement here, but
> I submit for consideration/discussion.

Before I start comment, I would prefer not break the compatibility. It
will break things and give surprises. That said, sometimes braking
things is necessary to make progress.

In case we want break things, we could introduce new or rename applets.
That way the current applet does not break.
 
> * As with "apk index" -> "apk mkindex", I'd find it easier if we aliased "apk
>   update" to something less similar to "apk upgrade": perhaps "apk pull"?

apk pull reminds me of git pull. (which will do both fetch and merge),
but is an option yes.

other options:
  apk (re)fresh
  apk fetchdb
  apk syncdb

I'm not convinced it is worth it though.

maybe a single 'apk -U'?


...

> * for backwards compatibility, "apk fetch -R" is still honored, though "apk
>   fetch -D" is now the preferred form. It may be confusing to have "apk fetch
>   -D" and "apk fetch -R" have the same functionality, so we could consider
>   immediately deprecating "apk fetch -R" more forcefully, for example by
>   issuing a warning message.
>
> * As I mentioned above, it'd be nice if "apk info -D/-R" recursed over more
>   than a single level of dependencies, or at least if there were an option to
>   do so.

As mentioned before. I think i prefer -R for 'recursive' over -D.

I'm not sure apk info --recursive makes sense. When is it needed?

...

> * One of the patches below deprecates short-form "apk info -i", for reasons
>   described in the commit. Now, the following proposal is probably just my own
>   taste. But I'd suggest deprecating a bunch more of the short-form options:
>   "apk -p", "apk fetch -s", "apk index -x", "apk upgrade -a", and all of "apk
>   info -IPswt". In the first two cases, because these are unusual actions
>   anyway and the short-form options aren't very memorable. It's easier and
>   clearer in practice to just use the long form; and then the apk-tools option
>   namespace will be clearer.

Yes, but I use --root fairly often, when setting up a temp sysroot. The
-p means 'prefix'.

apk fetch -s is useful to list contents of an uninstalled package:
  apk fetch --stdout pkg | tar -zt

apk index -x can be probably dropped yes. Its mostly used by scripts
and scripts should only use the long form.

But i have to admint that i tend to use the long options for --stdout
and --root.

>   In the third case ("apk index -x"), in part
>   because this conflicts with the different meaning introduced above for "-x"
>   wth "apk search." In part also because there's the confusing variety of "apk
>   -X/--repository", "apk version -I/--indices", "apk index -x/--index". In the
>   fourth case ("apk upgrade -a"), because it conflicts with the different
>   meaning for "-a" ("--all") in some other apk commands. In the case of the
>   "apk info" options: -I already has a different meaning for "apk version",
>   plus I already suggested not using its relative "-i". Additionally, "-I" and
>   "-P" are different in the character of their behavior from other capital
>   letter short-form options for "apk info" (-L, -W, -R, -D). It seems clearer
>   to just use the long forms for "-I" and "-P"; plus these are going to be rare
>   actions in any case.

>   For "apk info -swt": it's hard to remember which
>   output-selecting options have short-forms (and what they are) and which
>   don't. It'd be cleanest to just honor "-d" for "--description" and have the
>   other output options be long-form only. Also, "-s" for "apk info" would
>   conflict with the meaning of "-s" for "apk fetch", if we chose to retain
>   that.

'apk info -s' for size, like 'du -s'

maybe change 'apk fetch -s' to 'apk fetch -O' similar to 'tar -O' (and
'wget -O -')

...

> * "apk info" and "apk search" have different output styles, and interact with
>   "-q" and "-v" differently. Here is the current behavior:
> 
>     apk info:     list all installed packages, without -1.0-r0 suffixes
>     apk info -v:  list all installed packages, with -1.0-r0 suffixes
>     apk info -vv: list all installed packages, with -1.0-r0 suffixes, also list
>                   descriptions
>     apk info -v [moreoptions] packagename: machine-friendly output
> 
>     apk search substring:    list matching packages, with 1.0-r0 suffixes
>     apk search -q substring: suppress -1.0-r0 suffixes
>     apk search -v substring: list matching packages plus descriptions, on one line
> 
>   I observe also that "apk info" always seems to ignore "-q", and "apk version
>   -q" is, perversely, much more verbose than "apk version".
>   
>   This is all confusing and hard to remember. It'd be nice if we could
>   standardize on a single mapping between output formats and options, perhaps
>   following the pattern of "apk search".

Yeah, apk info output format have annoyed me too, specially the -q
thingy since it makes it hard to use in scripts.

How about we introduce 'apk list' or 'apk ls' to list installed packages?

apk ls:		list installed packages, with 1.0-r0 suffixes
apk ls -q:	list installed packages, without 1.0-r0 suffixes
apk ls -v:	list installed packages, with description
apk ls GLOB...:	list installed package which fnmatches GLOB(s)

Me and Timo as talked about a 'world' applet but a --world option could
solve that.

apk ls --world:	list world

Then 'apk info' would be more a tool to give information about
specified packages.

I am also missing: 'apk info --origin' to print the aport it comes from.

Maybe we could introduce 'apk info --format FORMAT' where format could
have % modifiers that corresponds to the field in installed db:

 %C  checksum
 %P  package name
 %V  version
 %A  arch
 %S  package size (apk)
 %I  installed size
 %T  description text
 %U  homepage
 %L  license
 %o  origin (aport name)
 %m  package maintainer
 %t  timestamp
 etc...

that way you could sort installed packages by size:

  apk info --format "%I %P" '*' | sort -n

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] futher apk ideas (WAS: [PATCH 00/15] apk-tools UI fixes/refinements)

Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20130628210007.293d7fb2@vostro>
In-Reply-To
<20130628163747.GB1712@zen.nyu.edu> (view parent)
Sender timestamp
1372442407
DKIM signature
missing
Download raw message
On Fri, 28 Jun 2013 12:37:47 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> Thanks Natanael and Timo for your comments. I'm glad we're mostly on
> the same page about these things. Much of what I threw out was just to
> invite reactions.
> 
> I'll have a look at what you've already committed and rebase the
> commits Timo asked me to separate out, shortly. This is just to
> respond to some of your comments.
> 
> I'll split out the discussion of -R/-D and the logging to separate
> emails.
> 
> 
> On Fri, Jun 28, 2013 at 11:13:33AM +0200, Natanael Copa wrote:
> > >  static struct apk_applet apk_add = {
> > >  	.name = "add",
> > > -	.help = "Add/update PACKAGEs to main dependencies and
> > > install them",
> > > +	.help = "Add PACKAGEs to main dependencies and install
> > > (or upgrade) "
> > > +		"them, while ensuring that all dependencies are
> > > met", .arguments = "PACKAGE...",
> > >  	.open_flags = APK_OPENF_WRITE,
> > >  	.context_size = sizeof(struct add_ctx),
> > 
> > it could have been: (or upgrade, if -u is given)
> 
> How about this comment message for "apk add": "Register package in
> 'world' and install it, if necessary, while ensuring that all
> dependencies are met"
> 
> Perhaps adding, either there or on the help for the "-u" flag,
> something like "If the package is already installed, `apk add`
> ignores any updates that may be available, unless the `-u` option is
> provided"

Mmm... right. I originally wanted to have "apk --help" be nice looking
on 80 char wide displayes, and tried to keep them as small as possible.
Especially the applet descriptions.

I wonder if it would make sense to have short and long descriptions.

We were talking with ncopa that we really should auto-generate manpages
from the apk --help (either by doing a script to extract these message;
or at build time have extra applet 'asciidoc' to generate it).

> On Fri, Jun 28, 2013 at 11:19:03AM +0200, Natanael Copa wrote:
> > > @@ -183,8 +183,8 @@ static int ver_main(void *pctx, struct
> > > apk_database *db, struct apk_string_array 
> > >  static struct apk_option ver_options[] = {
> > >  	{ 'I', "indexes",	"Print description and versions
> > > of indexes" },
> > > -	{ 't', "test",		"Compare two given
> > > versions" },
> > > -	{ 'c', "check", 	"Check if the given version
> > > string is valid" },
> > > +	{ 't', "test",		"Compare two given
> > > versions, output '<' '=' or '>'" },
> > > +	{ 'c', "check", 	"Check the given version
> > > strings, output any that are invalid" }, { 'a',
> > > "all",		"Consider packages from all repository
> > > tags" }, { 'l', "limit",		"Limit output to packages
> > > with status matching one of LIMCHARs", required_argument,
> > > "LIMCHARs" },
> > 
> > shouldn't it be a comma (,) in there?
> > 
> > ...output '<', '=' or '>'
> 
> If you like. I'll have a look to see whether this is a commit you want
> me to re-supply.

I pushed this commit with the comma added.

> > > @@ -192,7 +192,8 @@ static struct apk_option ver_options[] = {
> > >  
> > >  static struct apk_applet apk_ver = {
> > >  	.name = "version",
> > > -	.help = "Compare package versions",
> > > +	.help = "Compare package versions (in installed database
> > > vs. available) "
> > > +		"or do tests on literal version strings (with or
> > > without -rN suffixes)", .open_flags = APK_OPENF_READ,
> > >  	.context_size = sizeof(struct ver_ctx),
> > >  	.num_options = ARRAY_SIZE(ver_options),
> > 
> > Can we drop the "(with or without -rN suffixes)" part? it looks
> > like -r -N options...
> 
> If you like. Is there some other way we might communicate the same
> thing? Otherwise there's no way for someone to figure this out except
> by experimenting. Which isn't sooo bad.

This is also pushed with the modification done.

> Right, the version I was originally developing these patches against
> would always give the warning, that's why I reworded it. I hadn't
> noticed that the logic had now changed.
> 
> I like the idea that Natanael and Timo were discussing of just using
> installed dependencies when self-upgrading---if the ABIs permit.

Ok. Since everyone seems to like it, I'll that then.

> > I think it should do this automatically. But I really don't like
> > duplicating the code how to handle each option in all the applets.
> > 
> > I do like the idea of pushing these options down the applets that
> > actually use them. So seems we need some sort of "option group"
> > support.
> 
> I understand where you're coming from. Pragmatically, though, the
> option-handling code is just a single bit-setting in each case.
> Replacing this with a duplicate bit-setting to indicate the "option
> group" doesn't seem to gain much.
> 
> On the other hand, maybe there are broader benefits to introducing
> option groups. Also, it's true that there is the duplicated usage
> message.

More importantly, if I code a new feature that belongs in the same
"option group", I don't want to add it in 4 applets. Or if I update the
description, I don't want to change it in 4 places. So yes, this is
definitely needed; even if it is only static inline function parsing
the options in default: block, and #define providing the options for
the applet structure.

But I'd rather make it more formal option group - so the man pages
could note that appropriately. And document each such group only once.
Instead of duplicating the information for each applet.

> On Fri, Jun 28, 2013 at 03:46:31PM +0200, Natanael Copa wrote:
> > apk pull reminds me of git pull. (which will do both fetch and
> > merge), but is an option yes.
> > 
> > other options:
> >   apk (re)fresh
> >   apk fetchdb
> >   apk syncdb
> > 
> > I'm not convinced it is worth it though.
> > 
> > maybe a single 'apk -U'?
> 
> Right, "git pull" was the model for my suggestion. "git fetch" is the
> closer analogy, but "apk fetch" is already used.
> 
> I like the idea of honoring bare "apk -U/--update-cache" the best. I
> think implementing that would require somewhat more ambitious code
> changes.

I quite like update/upgrade. But I do understand that it can be
problematic for some. We could override "apk fetch" without arguments
to get the indexes, but not sure if that is ideal either. Of the above
candidates I prefer "apk -U". It might make sense to change the long
name to plain --update, or --update-index (instead of --update-cache;
which is legacy thing when "cache" contained only indexes and not
packages. there's the separate "cache" applet now to manage the real
"cache").

> On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> > On Thu, 27 Jun 2013 15:28:45 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> > 
> > > * It'd be nice if "apk version" also displayed which repository an
> > > upgrade would come from.
> > 
> > It shows the pinning. For the exact repositories, one can now use
> > "apk policy <pkgname>". Do note that "apk version" says the latest
> > version, not the version it would upgrade to.
> 
> Wow, I didn't realize that at all.
>
> > Apk version is a wee bet overloaded, as it can do many unrelated
> > things. Might be time to split it.
> 
> I agree. Should some of this functionality be merged with the new
> policy applet? Haven't yet sorted that out in my mental map.

I was thinking to separate:
 version -> upgrade --analyze (and make it calculate the real upgrade)
   (for old style output: upgrade --analyze --latest)
 version -t -> new verstr applet
 version -c -> new verstr applet
 version -I -> index --version, policy --index, or ideas?

And nuke version applet completely.

> On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> > On Thu, 27 Jun 2013 15:28:45 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> > 
> > > * Is "--overlay-from-stdin" really a generic option, or like
> > > --clean-protected and --purge does this option too only apply to
> > > some of the applets?
> > 
> > It applies like --clean-protected. Applets that commit things to
> > database use it. In practice it is only used on tmpfs root setups
> > during initramfs bootstrap.
> 
> Ok, then should it also be pushed down into the applets that use it?
> Or the appropriate "option group"?

Correct. Should go to same "option group" with all these. Basically the
option group would be for parameters that affect committing changes to
repository.

Though, the overlay-from-stdin option is quite special. I'm actually
thinking if we should change the bootstrap code to have it's own
applet. And implement --initdb and --overlay-from-stdin only in that.

> On Fri, Jun 28, 2013 at 02:36:45PM +0200, Natanael Copa wrote:
> > On Thu, 27 Jun 2013 15:28:45 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> >  
> > > 1. One set of changes is that we move some options that are now
> > > listed in the "generic options" usage block, but which don't in
> > > fact apply to all applets, into the applet-specific option set
> > > for the applets that use them. This applies to -U/--update-cache,
> > > --purge, and --clean-protected.
> > 
> > I think this is good. I am not 100% sure but I think that the short
> > form id integer might need to be universally unique.
> 
> Is that right? They can't even be duplicated between applets? I think
> there is some such duplication already in the code base. But this is
> just going by distant memory.

Duplicates between applets is ok. Uniqueness is needed with respect to
global options and per-applet options. If doing "option groups" then
that would need to be added to list.

Currently in case of duplicates, the global flags take precedence.

> On Fri, Jun 28, 2013 at 03:46:31PM +0200, Natanael Copa wrote:
> > 
> > apk fetch -s is useful to list contents of an uninstalled package:
> >   apk fetch --stdout pkg | tar -zt
> > 
> > ...
> > 
> > maybe change 'apk fetch -s' to 'apk fetch -O' similar to 'tar
> > -O' (and 'wget -O -')
> 
> I wasn't suggesting to eliminate the functionality, just the
> short-form option name "-s". I like the "-O" short-form much better.

Yes, -O <target> sounds good.

> On Fri, Jun 28, 2013 at 02:36:45PM +0200, Natanael Copa wrote:
> > On Thu, 27 Jun 2013 15:28:45 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> >
> > > For the most part, these UI tweaks don't introduce anything that
> > > will break existing behavior---except in 1 place (or perhaps
> > > 1-and-a-half places), which I'll describe below...
> > 
> > I am a bit sceptic to this kind of changes. It basically means that
> > there are some things that simply cannot be used in scripts...
> 
> I understand. I was trying very hard to minimize the breakage. The
> -R/-D stuff needs more discussion. The "-and-a-half" thing I was
> referring to above was about "apk info -i", but that seems to be
> currently broken anyway (also the long form).
> 
> I was thinking we should make sure the public scripts use long-form
> options (I've verified that many of them already do, except for a
> bunch of uses of -q). I was thinking also that where possible,
> changes be introduced like this:
> 
>         * first the new applet name/option name is enabled, and the
>           old names are still honored, but the usage message suggests
> to use the new forms.
>         * a bit later, the old forms are no longer listed in the usage
>           message, but they are still honored, except that we also
>           at the same time emit a message to stderr.
> 
> This won't break anything that doesn't capture stderr.
> 
> Also when I suggest "eliminating" short option-names, I just
> mean easing them out of the recommended usage and so
> on, as above, but---where possible---still honoring them.
> 
> It's just in a few places that things really invite being cleaned up
> in a way that requires more breakage. The "apk info -R" is the
> dominant example. I wholly agree this needs more discussion and
> thought.
> 
> > ... unless we
> > provide a simple way for a script to fish out the apk scripting
> > "api" version.
> > 
> > Maybe introduce apk --api-version
> > 
> > if empty, then its current api, then whenever we change the
> > scripting 'api' or output format, we bump the "api-version" number.
> > 
> > That way scripts has a way to deal with this kind of changes in
> > future. like:
> > 
> > apk_api="$(apk --api-version 2>/dev/null)"
> > : ${apk_api:=0}
> > 
> > if [ $apk_api -le 1 ]; then
> > 	apk_mkindex="apk index";;
> > else
> > 	apk_mkindex="apk mkindex";;
> > fi
> > 
> > $apk_mkindex *.apk .... etc
> 
> That's heavy-handed. Maybe it might be called for in the end, but I
> hope we can find some lighter-weight and elegant solution. What I
> described above wouldn't introduce any breakage with respect to "apk
> index"; we'd just eventually not be documenting its existence, but
> would continue to honor it.
> 
> 
> On Thu, 27 Jun 2013 15:28:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> 
> > * "apk info" and "apk search" have different output styles, and
> > interact with "-q" and "-v" differently. Here is the current
> > behavior:
> > 
> >     apk info:     list all installed packages, without -1.0-r0
> > suffixes apk info -v:  list all installed packages, with -1.0-r0
> > suffixes apk info -vv: list all installed packages, with -1.0-r0
> > suffixes, also list descriptions
> >     apk info -v [moreoptions] packagename: machine-friendly output
> > 
> >     apk search substring:    list matching packages, with 1.0-r0
> > suffixes apk search -q substring: suppress -1.0-r0 suffixes
> >     apk search -v substring: list matching packages plus
> > descriptions, on one line
> > 
> >   I observe also that "apk info" always seems to ignore "-q", and
> > "apk version -q" is, perversely, much more verbose than "apk
> > version". 
> >   This is all confusing and hard to remember. It'd be nice if we
> > could standardize on a single mapping between output formats and
> > options, perhaps following the pattern of "apk search".
> 
> 
> On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> > 
> > It might be also possible now to merge 'search' and 'info' applets
> > together. The fundamental difference is that info works with
> > installed packages, and search works with available packages - thus
> > info does have some extra information output that is available only
> > with installed packages. But all in all, most of the functionality
> > is shared.
> 
> Maybe. The main conflicts I can think of are with bare "apk info" vs
> bare "apk search", and with "apk info --rdepends" vs "apk search
> --rdepends". Also "apk info ..." requires an exact package name,
> right? whereas "apk search ..." defaults to accepting a glob pattern.
> 
> I don't mind having the separate applets.

True. With some thought, these could be merged to one .c file even if
we expose two separate applets. I would definitely want unified output
format for these.

Possibly also implement --json or similar for machine parseable output.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] futher apk ideas (WAS: [PATCH 00/15] apk-tools UI fixes/refinements)

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130630200534.19f3ce06@ncopa-laptop.res.nor.wtbts.net>
In-Reply-To
<20130628163747.GB1712@zen.nyu.edu> (view parent)
Sender timestamp
1372615534
DKIM signature
missing
Download raw message
On Fri, 28 Jun 2013 12:37:47 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

> Thanks Natanael and Timo for your comments. I'm glad we're mostly on the
> same page about these things. Much of what I threw out was just to
> invite reactions.

Thanks for doing so. I think its good that we discuss this.

...

> On Fri, Jun 28, 2013 at 11:13:33AM +0200, Natanael Copa wrote:
> > >  static struct apk_applet apk_add = {
> > >  	.name = "add",
> > > -	.help = "Add/update PACKAGEs to main dependencies and install them",
> > > +	.help = "Add PACKAGEs to main dependencies and install (or upgrade) "
> > > +		"them, while ensuring that all dependencies are met",
> > >  	.arguments = "PACKAGE...",
> > >  	.open_flags = APK_OPENF_WRITE,
> > >  	.context_size = sizeof(struct add_ctx),
> > 
> > it could have been: (or upgrade, if -u is given)
> 
> How about this comment message for "apk add": "Register package in
> 'world' and install it, if necessary, while ensuring that all
> dependencies are met"
> 
> Perhaps adding, either there or on the help for the "-u" flag, something
> like "If the package is already installed, `apk add` ignores any updates
> that may be available, unless the `-u` option is provided"

ok with me.

...
 
> > > @@ -192,7 +192,8 @@ static struct apk_option ver_options[] = {
> > >  
> > >  static struct apk_applet apk_ver = {
> > >  	.name = "version",
> > > -	.help = "Compare package versions",
> > > +	.help = "Compare package versions (in installed database vs. available) "
> > > +		"or do tests on literal version strings (with or without -rN suffixes)",
> > >  	.open_flags = APK_OPENF_READ,
> > >  	.context_size = sizeof(struct ver_ctx),
> > >  	.num_options = ARRAY_SIZE(ver_options),
> > 
> > Can we drop the "(with or without -rN suffixes)" part? it looks like -r -N options...
> 
> If you like. Is there some other way we might communicate the same
> thing? Otherwise there's no way for someone to figure this out except by
> experimenting. Which isn't sooo bad.

How about "(with or without revision suffixes)"?

...
> On Fri, Jun 28, 2013 at 03:46:31PM +0200, Natanael Copa wrote:
> > On Thu, 27 Jun 2013 15:28:45 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> > > Here are some further ideas for changes that I DON'T try to implement here, but
> > > I submit for consideration/discussion.
> > > ...
> > > * As with "apk index" -> "apk mkindex", I'd find it easier if we aliased "apk
> > >   update" to something less similar to "apk upgrade": perhaps "apk pull"?
> > 
> > apk pull reminds me of git pull. (which will do both fetch and merge),
> > but is an option yes.
> > 
> > other options:
> >   apk (re)fresh
> >   apk fetchdb
> >   apk syncdb
> > 
> > I'm not convinced it is worth it though.
> > 
> > maybe a single 'apk -U'?
> 
> Right, "git pull" was the model for my suggestion. "git fetch" is the
> closer analogy, but "apk fetch" is already used.
> 
> I like the idea of honoring bare "apk -U/--update-cache" the best. I
> think implementing that would require somewhat more ambitious code
> changes.

I don't think the current 'apk update' is that bad. I know users are
used to it so I'm slightly sceptic to change it.

...

> On Fri, Jun 28, 2013 at 01:21:45PM +0300, Timo Teras wrote:
> > On Thu, 27 Jun 2013 15:28:45 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> > 
> > > * One of the patches below deprecates short-form "apk info -i", for
> > > reasons described in the commit. Now, the following proposal is
> > > probably just my own taste. But I'd suggest deprecating a bunch more
> > > of the short-form options:
> > 
> > Agreed, these could do a little rework. Most of apk flags are what
> > they are due to historical reasons (from the shell based apk-tools
> > 1.x), and the rest just "evolved" when needed.
> > 
> > Redesigning the current set of flags to be "unified" would be a good
> > thing.
> 
> Again, this was just to start discussion. But I'm glad our
> general inclinations here are in line.

+1

...

> On Fri, Jun 28, 2013 at 02:36:45PM +0200, Natanael Copa wrote:
> > On Thu, 27 Jun 2013 15:28:45 -0400
> > Dubiousjim <dubiousjim@gmail.com> wrote:
> >
> > > For the most part, these UI tweaks don't introduce anything that will break
> > > existing behavior---except in 1 place (or perhaps 1-and-a-half places), which
> > > I'll describe below...
> > 
> > I am a bit sceptic to this kind of changes. It basically means that
> > there are some things that simply cannot be used in scripts...
> 
> I understand. I was trying very hard to minimize the breakage. The -R/-D
> stuff needs more discussion. The "-and-a-half" thing I was referring to
> above was about "apk info -i", but that seems to be currently broken
> anyway (also the long form).
> 
> I was thinking we should make sure the public scripts use long-form
> options (I've verified that many of them already do, except for a bunch of uses
> of -q). I was thinking also that where possible, changes be introduced
> like this:
> 
>         * first the new applet name/option name is enabled, and the
>           old names are still honored, but the usage message suggests to
>           use the new forms.
>         * a bit later, the old forms are no longer listed in the usage
>           message, but they are still honored, except that we also
>           at the same time emit a message to stderr.
> 
> This won't break anything that doesn't capture stderr.
> 
> Also when I suggest "eliminating" short option-names, I just
> mean easing them out of the recommended usage and so
> on, as above, but---where possible---still honoring them.

Agree.

Lets first figure out where we want end up and then we can talk how to
get there.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] futher apk ideas

Details
Message ID
<20130701145729.GC1550@zen>
In-Reply-To
<20130701151533.079b3256@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1372690649
DKIM signature
missing
Download raw message
On Mon, Jul 01, 2013 at 03:15:33PM +0200, Natanael Copa wrote:
> On Fri, 28 Jun 2013 13:19:45 -0400
> Dubiousjim <dubiousjim@gmail.com> wrote:
> >
> > Again, I'm not especially fond of the particular choice -N/--needed.
> > Just using it because I don't have something better.
> 
> agree. Not too fond of -N/--needed either. 'needed' sounds like a synonym for 'depends'

Whoops, I meant it to be --needers, which is even uglier but less likely
to be misinterpreted.
> 
> maybe -b/--required-by or some combination of -b and --needed-by/--required-by.
> 
> for recursing the reverse deps (apk del/apk info) maybe
> --recurse-required-by or --recurse-needed-by
> 
> I think -b and -B are 'free'. 'B' as in required-'B'y/needed-'B'y or
> 'B'ackwards.

I like this idea. I was regretting that -U was unavailable, for
--upwards, but something like -B/--needed-by scratches the same itch.
Hadn't considered that.

Concerning -r/--rdepends: well, in the first place I hanker for
consistency, and if this is the way to get it, ok. Though I'm not
enthusiastic about using -r or --rdepends.  Maybe it's just a bad
association I have with MacPorts, who do use that, and every time I go back
to using MacPorts for something, after months away, I get all the option names
confused with each other. If we're using something -R-like for
"recurse", I'd prefer something un-R-like for reverse dependencies. The
-B or -b options look more appealing.

> > > I think recursive operation makes no sense for apk info, but for apk
> > > search, yes.
> > 
> > No, I've several times had to hand-script recursive operations for "apk
> > info". If you're just going downwards, then you could use apk search
> > too; but you might want to go recursively upwards, limited just to
> > installed packages.
> 
> When and why would you need something like that?

Machine A had gradually accumulated a lot of unorganized entries in
/etc/apk/world. Now I'm setting up machine B (another Alpine machine)
and machine C (an OS X machine, using MacPorts). I want to clean up the
world on machine A so as to be able to more clearly review which
of the entries there are redundant (i.e., it's required by some other
packages), and in which cases where there's a redundancy do I want to
leave it in place, and in which other cases do I want to remove the
entry from /etc/apk/world, though leaving the package installed.
This is all so that I can have the cleanest view of what's on machine A,
so as to make it easier to decide what I want and what I don't want on
machines B and C. Stuff like that.

Perhaps I could have just used `apk del --simulate`. That option hadn't
occurred to me. Instead I crafted a complex, ad hoc shell command.


> > Options for fix command:
> >   -R, --recursive         Recursively fix all dependencies too
> >   -d                      Synonym for -R (deprecated)
> 
> Those are good IMHO.
> 
> >   -r, --reinstall         Reinstall the package (default) <--- would
> > prefer not to have "apk del -r" be canonical, to avoid confusion with
> > other uses of "-r" like this
> 
> We could maybe remove (or mark as deprecated) -r/--reinstall for apk
> fix, since it is the default now anyways.

+1


> > Options for info command: (or "apk info --world", if we go that route)
> >   -d, --description       Print description for PACKAGE
> >   -D, --depends           List packages that the PACKAGE (directly) depends on
> >   -R                      Synonym for -D (deprecated)
> 
> I'm ok with those. (But i think I'd be ok to keep -R too for --depends)
> 
> >   -N, --needed            List all installed packages (directly) depending on PACKAGE
> >   -r                      Synonym for -N (deprecated)
> > 
> > Except we might introduce breakage here and have -R combine with -D and
> > -N to make them recursive.
> 
> I understand what you mean, and, yes you definitively have a point
> here.
> 
> But, lets say that you want figure the total size (including
> depends). Now, you'd want run 'apk info --recursive -s' but you'd don't
> want print the --depends. (specially if we fix 'apk info -q -s pkg' to
> print '<size> <pkgname>' so it could be sort -n, or similar)
> 
> So, basically, we need differ 'print depends' and 'run recursively on
> depends'. I don't think we can use -R in combination with
> --depends/--needed/--rdepends.

That's a good point.

-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] futher apk ideas

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20130701151533.079b3256@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20130628171945.GD1712@zen.nyu.edu> (view parent)
Sender timestamp
1372684533
DKIM signature
missing
Download raw message
On Fri, 28 Jun 2013 13:19:45 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:

...
> > What if you want list 'depends' without recursing? (apk info <show the depends>)
> 
> Right, I agree it should be possible to do both. I was thinking maybe
> "apk info -D" for all the depends, recursively, and "apk info -D -1" for
> just a single level. But maybe it'd be better to have "apk info -D" just
> do the single level (as it does now), and "apk info -D --recursive" do
> the recursing. And maybe it'd be better to use "-R" as the short-form
> for "--recursive".
> 
> Instead of -R/--rdepends, then, we'd need something like --N/--needers.
> But perhaps we can find a better name.

I like -r/--rdepends better than -N/--needers.

...

> > I think recursive operation makes no sense for apk info, but for apk
> > search, yes.
> 
> No, I've several times had to hand-script recursive operations for "apk
> info". If you're just going downwards, then you could use apk search
> too; but you might want to go recursively upwards, limited just to
> installed packages.

When and why would you need something like that?

Situations where I have needed something similar:
* figuring out build order (but then I need to use makedepends so I can
  not really use apk here)
* figuring out which files are needed to get downloaded to build an
  iso. I use apk fetch --recursive --simulate for this
  http://git.alpinelinux.org/cgit/alpine-iso/tree/Makefile#n34
* figure out what packages would get installed (use apk add --simulate)
* figure out what package would get deleted (use apk del --simulate)

> > When i think of it, --recursive only make sense downwards in dependency
> > tree (similar when talking about directories in file system) with the
> > exception of 'apk del'
> 
> As I said, I can remember needing this several times over the past
> months. Don't remember the details though; or anyway, can't remember
> them in a form where I can easily abstract away the idiosyncracies of
> what I happened to be doing.

It would be interesting to know what kind of problems you needed to
solve. Might be it could be solved in a different way.

(I must admit, I am not too happy with apk fetch --simluate 2>&1 | sed
's/^Downloading: //' so yes there is room for improvements here)
 
> > The above summary would be change to (* means a breakage from current):
> > Options for del command:
> >   -r, --rdepends          Recursively delete all top-level reverse dependencies
> >                           too
> > Options for fix command:
> > * -R, --recursive         Recursively fix all dependencies too
> > 
> > Options for fetch command:
> >   -R, --recursive         Recursively fetch the PACKAGE and all its dependencies
> > 
> > Options for audit command:
> > * -R, --recursive         Recursively list individually all entries in new directories
> > 
> > 
> > Since -R now means 'recursive' and -d already means 'description' we
> > could change apk info's non recursive to -D
> > 
> > Options for info command:
> > * -D, --depends           List packages that the PACKAGE depends on
> > 
> > But i am also ok with keeping 'apk info -R' as an exception. (i think
> > -R was originally taken to correspond to BSD's pkg_info -R)
> > 
> > how does that sound?
> 
> 
> How about this:
> 
> 
> Options for del command:
>   -N, --needed            Recursively delete all top-level reverse dependencies too
>   -r                      Synonym for -N (deprecated)

I kinda still prefer -r/--rdepends

> No option is needed here to recursively delete all downward dependencies
> that aren't required by anything in 'world', right? Because we are
> always going to do that by design.
> 
> 
> Options for fix command:
>   -R, --recursive         Recursively fix all dependencies too
>   -d                      Synonym for -R (deprecated)

Those are good IMHO.

>   -r, --reinstall         Reinstall the package (default) <--- would
> prefer not to have "apk del -r" be canonical, to avoid confusion with
> other uses of "-r" like this

We could maybe remove (or mark as deprecated) -r/--reinstall for apk
fix, since it is the default now anyways.

> Options for fetch command:
>   -R, --recursive         Recursively fetch the PACKAGE and all its dependencies

Good.

> Options for audit command:
>   -R, --recursive         Recursively list individually all entries in new directories
>   -r                      Synonym for -R (deprecated) <-- as with "apk
> fix -r"

Good.
 
> Options for info command: (or "apk info --world", if we go that route)
>   -d, --description       Print description for PACKAGE
>   -D, --depends           List packages that the PACKAGE (directly) depends on
>   -R                      Synonym for -D (deprecated)

I'm ok with those. (But i think I'd be ok to keep -R too for --depends)

>   -N, --needed            List all installed packages (directly) depending on PACKAGE
>   -r                      Synonym for -N (deprecated)
> 
> Except we might introduce breakage here and have -R combine with -D and
> -N to make them recursive.

I understand what you mean, and, yes you definitively have a point
here.

But, lets say that you want figure the total size (including
depends). Now, you'd want run 'apk info --recursive -s' but you'd don't
want print the --depends. (specially if we fix 'apk info -q -s pkg' to
print '<size> <pkgname>' so it could be sort -n, or similar)

So, basically, we need differ 'print depends' and 'run recursively on
depends'. I don't think we can use -R in combination with
--depends/--needed/--rdepends.

*if* we want keep the possibility open to run apk info recursively, we should probably use:
-R(?)/--recursive       recursively display info for dependency packages
-?/--recursive-reverse  Recursively display info for packages required by the specified


> Options for search command: (or "apk info" without "--world", if we go
> that route)
>   -d, --description       Search package descriptions (implies -a)
>   -N, --needed            List all (installed and uninstalled) packages (directly) depending on PACKAGE
>   -r                      Synonym for -N (deprecated)
>   -R                      Combines with -N to make it recursive
> 
> 
> Again, I'm not especially fond of the particular choice -N/--needed.
> Just using it because I don't have something better.

agree. Not too fond of -N/--needed either. 'needed' sounds like a synonym for 'depends'

maybe -b/--required-by or some combination of -b and --needed-by/--required-by.

for recursing the reverse deps (apk del/apk info) maybe
--recurse-required-by or --recurse-needed-by

I think -b and -B are 'free'. 'B' as in required-'B'y/needed-'B'y or
'B'ackwards.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)