http://bugzilla.wpkg.org/show_bug.cgi?id=121 --- Comment #3 from Rainer Meier <r.meier at wpkg.org> 2008-05-29 00:56:12 --- Thanks for the commend. I did not read through in detail yet. But let's construct a simple test example. Profile x: Includes package a Profile y: Depends on profile x but excludes acrobat-reader Package a depends on acrobat-reader package acrobat-reader package depends on package b Then somebody assigns profile y to a host. If you modify the method to collect the packages (excluding the excluded ones) then the package tree might contain package a (but not acrobat-reader and thus not package b). But during installation WPKG will try to apply package a which is a part of the mandatory packages applicable for the host. During installation of package a WPKG discovers the dependency and needs to force installation of acrobat-reader (yes, the algorithm will do this). Of course the install algorithm can be modified not to install acrobat-reader in this case but this would make package a to fail its installation (dependency missing) and thus resulting in a synchronization error during each synchronization. The only way out is that also package a is auto-excluded. Now the profile which should actually only exclude "acrobat-reader" already misses 3 packages - not to mention package eventually included by package b (dependency of acrobat-treader) using dependency, include or chain. And all this trouble just to assure that one package which might be heavily integrated into the dependency tree is not applied to a system? Why should one do this instead of simply not listing it in a generic profile applying to all hosts? To me it looks like the 'acrobat-reader' package in this example should be applied to only a minor number of hosts. So why not creating a 'lab-x' profile which includes the 'base' profile (without acrobat-reader) which adds exactly this package - and "lab-x" is assigned to a few hosts by name or IP match only. By experience I am sure that as soon as such a feature is available people will start doing very very nasty things with it - just because they are simple not aware of the "right" way to do it. The only way I could imagine to do such a thing is that the whole dependency tree has to be reverse-parsed for the excluded package and every package depending on the excluded one (and the ones depending on this one...) have to be removed from the tree. Probably packages which refer to the excluded one by include or chain do not need to be excluded as I do not consider "include" and "chain" as a "hard dependency" which means that a package installation is not considered to be failed if a package which is only "included" or "chained" fails. But it is definitely a show-stopper if a dependency cannot be installed (either by failed installation or if it is excluded). So an exclude specification will definitely require to remove also the packages which depend on the excluded one from the dependency tree. By the way - I am planning another enhancement which will allow to manually install packages on a host. These manually added packages will be maintained on the system (updated) even if they are not part of the profile. This would also allow to manually add adobe-acrobat to a few of the systems - even if not listed in _any_ profile. On all systems where it has been added manually it will remain and will be updated if the package on the server side is updated. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |