Same named packages, different dependencies

[Jeff Spaleta]

On Fri, 10 Dec 2004 06:52:44 +0100 (CET), Dag Wieers <dag at wieers.com> 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