X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25])
	(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id E498ADC0091
	for <alpine-devel@lists.alpinelinux.org>; Fri, 28 Jun 2013 17:19:50 +0000 (UTC)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B0C9E20B27
	for <alpine-devel@lists.alpinelinux.org>; Fri, 28 Jun 2013 13:19:45 -0400 (EDT)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
  by compute4.internal (MEProxy); Fri, 28 Jun 2013 13:19:45 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=date:from:to:subject:message-id
	:references:mime-version:content-type:in-reply-to; s=smtpout;
	 bh=x3ciQVGsV31Y9x2HYdViViaBE1Y=; b=DUSUZTgzFauJfqDY0StOAHdMK3hi
	gLvMIrDGXQtuh1+2ArysrPc4rEeh/B+NdUQ6v2lgVna8K+Umub6aWG6HQKjZFfDg
	GJat6AU1Os1e8gIQpMGp+0T5Tf7AxZcwYA+j8b5r+PtE6ut8HT/KuOAY1MHlqDxl
	ApHiWIQquw/JU08=
X-Sasl-enc: WFSMAWMAzcU/rverFt3vE8oANE6Z3iVSLO8mTavDjyDv 1372439985
Received: from localhost (unknown [216.165.95.73])
	by mail.messagingengine.com (Postfix) with ESMTPA id 7E6E46801C6
	for <alpine-devel@lists.alpinelinux.org>; Fri, 28 Jun 2013 13:19:45 -0400 (EDT)
Date: Fri, 28 Jun 2013 13:19:45 -0400
From: Dubiousjim <dubiousjim@gmail.com>
To: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] futher apk ideas
Message-ID: <20130628171945.GD1712@zen.nyu.edu>
Mail-Followup-To: alpine-devel@lists.alpinelinux.org
References: <cover.1372361242.git.dubiousjim@gmail.com>
 <20130628154631.4d18107d@ncopa-desktop.alpinelinux.org>
 <20130628163747.GB1712@zen.nyu.edu>
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130628163747.GB1712@zen.nyu.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)

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
---