Re: [A-A-P-develop] Re: Just some thoughts

On Tue, 30 Sep 2003, Bram Moolenaar wrote:

> Aschwin Marsman wrote:
> 
> > So for UNIX-like systems stable & latest are the same for vim when 
> > using the source.
> 
> Not exactly.  The stable version would lag behind a couple of weeks,
> until it's clear that patches don't cause new problems (on average 1 out
> of 10 patches needs another fix).

I'm so convinced of your quality software that I automagically update my
vim every time I log-in. But you're right, it doesn't always work, but
most problems that did appear didn't affect me. It's up to the maintainer
of the recipe, and you can always adapt a recipe to your needs.
 
> > For UNIX like systems also a binary package could be provided which
> > doesn't always have the latest patches, because somebody has to build
> > them and make them available.
> 
> Yes, and then the maintainer has to decide if the binary package is
> behind far enough to use the source code instead.

Off course. Maybe the maintainer has a build factory that builds the latest
version of an application automagically, that's also a good test.

> > On Windows currently binary stable is vim 6.2 core, but for source
> > stable could be vim with all patches. 
> 
> If there is a compiler that can be used.  You don't really expect "aap
> --install vim" to install a C compiler as a side effect, right?

If you specify: "aap --install vim VERSION=latest METHOD=source" I would
expect that, call me a mad man ;-). That will only have to be done once.
But if you have a modem connection I would not recommend this...
 
> > Agreed, we would have an option delivery method with a certain default
> > which can be overruled by the user. A comma separated list comes to mind.
> 
> To stick with Aap standards, a white-separated list is more appropriate.
> I try to prevent adding more mechanisms to Aap when it's not really
> needed.

Ok, I thought a comma separated list is a local choice but I don't care.
 
> > > > Let's try to quickly take some decisions before it gets to complicated.
> > > 
> > > For selecting the desired version:
> > > 
> > > 	aap --install pkgname VERSION=stable
> > > 	aap --install pkgname VERSION=latest
> > > 
> > > Where "stable" is the default.  It's possible that both versions are the
> > > same or that some packages offer more different versions.
> > 
> > OK. (Why do you prefer VERSION= i.s.o. --version=?)
> 
> This is the standard method to pass values to a recipe.  An argument
> such as "--version" would need to be implemented in the Aap code.  And
> "--version" already has a different meaning anyway (print the Aap
> version and exit).

You're right. As a user convenience an unknown option could be converted
to the aap desired format. For a user --version is more natural than VERSION.
(--option => OPTION). But let's get this train rolling i.s.o solve all 
problems at once.
 
> > > Is that simple enough?
> > 
> > TRANSFER=ftp,cvs,svn,bk,rsync,scp?
> 
> Is that simple !?!?

As a simple start I would support TRANSFER=ftp. The other options can be
added when somebody feels like it. But it would be nice to have an abstraction
for transfering files so the recipe maintainer doesn't need to know if
ftp, cvs, ... is used.
 
> > > I think the real work is to figure out dependencies and make it work on
> > > many different systems.  Before bothering the user with more choices.
> > 
> > That can be the thing that aap can do what other systems don't do so well,
> > but it all depends on the availability of up-to-date recipes.
> 
> Yes, the idea is that the maintainer takes over most of the burdens that
> the user would have for making choices and invoking the right commands.

That's in one sentence what I wanted to say this morning.
 
Kind regards,
 
Aschwin Marsman
 
--
[email protected]              http://www.marsman.org



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf