Date: Fri, 28 Jun 2013 15:46:31 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Dubiousjim <dubiousjim@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] futher apk ideas (WAS: [PATCH 00/15] apk-tools UI
 fixes/refinements)
Message-ID: <20130628154631.4d18107d@ncopa-desktop.alpinelinux.org>
In-Reply-To: <cover.1372361242.git.dubiousjim@gmail.com>
References: <cover.1372361242.git.dubiousjim@gmail.com>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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
---