[wpkg-users] [Bug 121] additional EXCLUDES node for profiles

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=121


Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.meier at wpkg.org




--- Comment #1 from Rainer Meier <r.meier at wpkg.org>  2008-05-28 23:02:06 ---
As I will be awai for some days I would like to give some comments on this.
Feel free to comment.

Personally I think this enhancement will break WPKG and create really a lot of
problems. It is completely incompatible with the WPKG package structure as it
is now. Why? Read on.


I had a quick look at the patch and it does currently not even take package
dependencies into account. The upcoming update of WPKG will allow dependencies,
includes and chained packages.
There was another request on the list asking for "black-listing" packages which
is the same request, just another name. However both requests do only work in
theory and just regarding a sub-set of the WPKG features. An excluded package
(package is not allowed to be installed for this profile) will not only
potentially break the dependency tree but it could also break an include chain
and thus "exclude" much more package than actually intended. Some packages
which belong to a profile might just "break away" as a package (which probably
depends, includes and chains others again) might just be omitted.

In addition I don't see the reason why WPKG should allow an administrator to
assign "broken" profiles to a host which are not compatible with the host and
then patchworking it to be somehow compatible.
In a company there might be different people responsible for profiles than for
packages. In any case there is no logical way to automatically resolve such
"conflicts" like package A depends on package B but package B is "excluded".
When using your patch, then you even do not take this case into account I think
(just had a quick look) so in this case package B is still applied (if another
one depends on it).

In such cases WPKG would have to fail also to install all packages which have a
dependency on the excluded one. The same algorithm be applied for chained
packages. Should 'excluded' packages be ignored when included by another
package? As I said this could break away some parts of the package tree - or
even corrupt it completely.

It will be very hard to trace such issues for a system administrator. In
addition you have to think about a dynamic system. Packages might start to
require other ones as they evolve. It's very easy to just "forget" to check all
possible includes, dependencies and chains to synchronize them with eventually
side-effects by excludes.

Of course we could ignore all these problems. But then I am definitely going to
quit the list and Bugzilla. I am not willing to trace such problems down to the
package tree.


In addition there are already mechanisms available to handle such things
properly. As I wrote on the list...

Just create consistent and working profiles. I am usually doing such things as
follows:

<host name="machine01" profile-id="basic" />
This profile contains then all packages which work on all machines.
In addition I have a host definition as follows for

<host name=".+" profile-id="default" />
The default profile _extends_ the basic profile and adds some more packages.

For example:

<profiles>
     <profile id="basic">
         <package package-id="firefox" />
         <package package-id="thunderbird" />
         ...
     </profile>

     <profile id="default">
         <depends profile-id="basic" />
         <package package-id="packageX" />
     </profile>
</profiles>

If you find another package not to work on a specific node than it has 
to be removed from the basic package. Admins can do such re-structuring 
at any time since WPKG does not care from which profile the package has 
been included. So if the host matches another profile but the packages 
are the same nothing will change for the host.

So I would strongly recommend keeping the profiles clean and working for 
each machine instead of assigning non-applying packages to a host and 
then starting to blacklist them since I think the results will be 
untraceable.

In addition my second advise is to create packages which work on all nodes. I
did not find any single package yet which I haven't been able to install on all
machines. There might be some special "drivers" or whatever but even these
packages can be written in a way they can be "applied" to the system.
There has been some discussion on the list once about a package which we then
installed using a CMD script which checks via DMI information if it should be
applied to this machine. If not, then it just exits with code 0 and WPKG thinks
it is installed properly. On machines it should be applied it simply executes
the installation routine. So the package works on all machines.

If this is not feasible or you're not able to write such generic packages, then
you might apply the approach above. Keep generic software in a "basic" profile
(applies to all systems). Then create another profile for specific machines
(for example a profile for all HPxy machines), use a depends on "basic" and
then just extend this profile by the HP specific packages for example.

This is much more transparent and easier to trace and it does not include any
hacks on the (potentially complex) dependency tree.


So my statement is clear. Confusing and non-generic feature potentially
breaking compatibility. I will not include it. It might work within your
environment. Feel free to keep the patch but do not expect support from my
side.

Fell free to comment and possibly convince me that this patch will not create
any problems in any environment and the hard requirement why we cannot live
without it.


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.