Hi Jeff,
I agree and I disagree with you..

What we have done for this release is:
Take  the "big blob" apt get  rpm
or take the rpm lists and throw out what you don't want.
The rpm lists can be created by taking the nodes apt get rpm and do
a rpm -qp --requires on it. This will produce a list of rpms that you
can edit and
install.

I completely agree that this is not a good way to handle this.
The solution has to allow for allowing a simple one shot setup with a
default config and
a tailored setup for sites that have special needs.

What we will do for future releases is we will classify the packages in
different categories and then build
multiple rpms.
The structure that we want to implement is along the following lines:

1) Core
     RPMS that contain the core services and their dependencies
     (core means: you can't run jobs without  them and there are no
choices to establish the functionality.
      this means that there will be no batch system, but client tools
for the file catalogue

2) List of Choices
      This list contains RPMs out of which you have to choose at least
one to get a working system, or provide a replacement for those offered
      An example for this are the storage managers and the LRMs. These
RPMs will depend on the Core to be present

3) Optional
     The take it or leave it list. Here you will find packages for local
fabric monitoring, packages that are not fully certified and the likes.
     They depend on the Core to be installed.

In addition we will produce  scripts that contain a sequence of apt
commands starting with the core and having all the other ones in. The
recommended
default selection will be active and alternatives will be commented
out. If a site is not too opinionated about what is installed (as long
as it works) the admins
will just run the script without changes, those who want to do
selections will edit this file.
The advantage of this compared to a flat RPM list is that the
complexity is significantly reduced.
An alternative is to control the inclusion by the config file.

The biggest problem I see is to get people agree on what is core and
what not.

          M"never right the first time"S

On Friday, Dec 10, 2004, at 14:05 Europe/Zurich, Jeff Templon wrote:

> Yo
>
> On Fri, 2004-12-10 at 13:53, Louis Poncet wrote:
>> Jeff Tank and spark are present but not configure (like your telnet
>> server)
>> If you want to deactivate a service rewrite the configure function put
>> it in functions/local
>> and it is done.
>>
>
> I'll be blunt ... if I am told package XYZ is optional software, but I
> am forced to install it (see below as well) anyway, how do I as a
> remote
> site person know, unless I check for each of these 'optional' packages,
> that they are really not turned on??  They are optional but installing
> them is not optional.
>
> This is not acceptable : if a package is not required, it should be
> perfectly fine to leave its installation off.  I'd go one step further,
> if it's optional the default should be NOT to install it.
>
> Guess I am gonna have to see what I can do to quattorize this
> installation instead:
>
> -bash-2.05b# rpm --erase lcg-spark-gcc32dbg
> error: Failed dependencies:
>         lcg-spark-gcc32dbg >= 1.3-6_sl3 is needed by (installed)
> lcg-WN-torque-2.3.0-sl3
> -bash-2.05b# rpm --erase lcg-spark-gcc32dbg --force
> rpm: only installation, upgrading, rmsource and rmspec may be forced
>
>         J "i really did want to use YAIM" T
>
>

************************************************************************
*******
Markus Schulz
CERN IT