On Fri, 10 Dec 2004 06:52:44 +0100 (CET), Dag Wieers <dag@xxxxxxxxxx> wrote: > If Smart was around, you wouldn't have ended up in whatever situation you > were. To me it's the lack of proper tools and Smart can change this for > the better. Assuming of course, the user knows with intimate precision, how they personally want to set up their per package priorities. The ability of any particular user to be able to set priorities, per package or per repository, only comes from personal experience. Priorities.. like most workarounds to any problem...are a reactive measure that users can take once they hit a problem. And while i don't have a problem making this available for advanced users, I am concerned about making all users rely on priorities as the primary solution. I'm much more interested in a solution at the repository level that suggests default interdependancies between repositories explicitly. So that when a repository builder, builds their packages expecting users to pull deps from another repository tree, its explicitly notated in the repository metadata as a default for packaging software to use. Or if repositories are built with specific peering policies like "this repo as a matter of policy should not overlap with packages from that other repo or that other repo" this can be in the metadata explictly. I'm concerned that if a package manager software is 'too smart', packaging problems inside a repository will be overlooked by users and never reported as a problem. Packaging problems do happen, and if the commonly used packaging tools aren't made aware of specific repository policy with regard to interdependancies packaging problems WILL be under-reported. And I'm wary of any solution that mixes package updates/installs with removals in the same step. I'm concerned about unintended package removal cascades due to packaging errors. Again, if the tool is 'too smart', less users will notice this as a packaging problem...and these situations will be under reported. -jef
