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. |