Re: Just some thoughts

Quoting Bram Moolenaar <[email protected]>:
> Aschwin Marsman wrote:
> 
> > When you want to use an application, there are some possibilities:
> > - get a binary package
> >   drawback: not always the latest version/patchlevel, you have to depend
> >   on another person for you to supply it
> > - get the source and build it yourself
> >   drawback: you need the tools and it takes more time than installing a
> >             binary package
> > - for most applications, there are two versions that are maintained:
> >   stable and latest/test. For some packages I always want the latest
> >   (vim in my case), for others I would like a stable package (the window
> >   manager).
> > 
> > What I would like to have is aap recipes for a lot of applications that
> > let my say:
> > aap --install <package> --version=stable|latest|..
> --delivery=binary|source|..
> > 
> > This would download all necessary software (include e.g. all patches for
> vim
> > if I specify latest), if needed build it and install it. This will make
> > use of the default configure/make/.. that's inside the package and
> supplies
> > a convience layer on top of it. Later the configure/make/... can be
> replaced
> > by the aap recipe if that's possible (You will need to have support of the
> > maintainer of the application, otherwise the aap recipe can become out of
> > sync when the configure/make/... is changed.).
> > 
> > Which options are needed is off course open for discussion, but I think
> > it would be nice to have a standard interface (options) that all aap
> > recipes support.
> > 
> > What do you think? 
> 
> I think this is a very good plan.  What I have done with packages so far
> is only the first step.  With a few more features, such as selecting the
> stable/latest version, it quickly becomes very useful.
> 
> If someone would like to work on this, I will certainly give my support.

First we will have to agree to have a standard interface (read options)
that will be used. It can become very complex if you want to be able
to support all configurations. Maybe we should limit ourself, at least
for now, to a simple but extensible interface.

If you take the Linux kernel as an example, there are some conventions,
do we want to support them all?
- The latest stable version (e.g. 2.4.22)
- The latest prepatch stable version (e.g. 2.4.23-pre5)
- The latest stable version with patches from Alan Cox (e.g. 2.4.22-ac4)
- The latest stable version with patches from BK (e.g. 2.4.22-bk27)
- The latest stable 2.2 version (e.g. 2.2.25)
- The latest beta version (e.g. 2.6.0-test6)

I think this is the worst possible example, but what do we want to support
for a start? (I use currently three of the above...). What will be said
to be stable? 2.4.22? And latest? 2.4.23-pre5 or 2.6.0-test6 or ...

Maybe vim is an easier example to begin with:
stable=6.2
latest=6.2.106
Although I wouldn't recommend bare 6.2...

How to differ between delivery method? binary/source, but from where?
ftp, cvs, BK, svn, ... Or is this up to the package maintainer?

Let's try to quickly take some decisions before it gets to complicated.

Who'se first?

Kind regards,

Aschwin Marsman

--
http://www.marsman.org              [email protected]


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