Date: Sun, 30 Jun 2013 20:05:34 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Dubiousjim <dubiousjim@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] futher apk ideas (WAS: [PATCH 00/15] apk-tools
 UI fixes/refinements)
Message-ID: <20130630200534.19f3ce06@ncopa-laptop.res.nor.wtbts.net>
In-Reply-To: <20130628163747.GB1712@zen.nyu.edu>
References: <cover.1372361242.git.dubiousjim@gmail.com>
 <20130628154631.4d18107d@ncopa-desktop.alpinelinux.org>
 <20130628163747.GB1712@zen.nyu.edu>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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
---