Enrique Zanardi <[EMAIL PROTECTED]> writes: > > However, let me make another suggestion: We add a new control field to our > > packages, namely `Distributor'. All Debian packages will get > > > > `Distributor: SPI' > > > > and everyone outside the project should use something else, e.g. > > > > `Distributor: KDE Project' (or how they call themselves--I don't > > know) > > > > Then we could extend dpkg/dselect/deity to check for this field and warn > > the user if he/she tries to mix such packages. Of course, there should be > > a way to override these warnings (just when someone tries to override some > > dependencies). > > That looks like a good proposal. We could define that a foo_A.deb from SPI > will always conflict with a foo_B.deb from other parties, no matter the > values for A and B.
The problem with this proposal is that there is no assurance that in fact the conflicting packages will have the same names; i.e., they might divide up the functionality in KDE into packages differently from the way that we do it. Won't our turning off --force-overwrite in 2.0 be a more realistic solution of this problem? Aren't most package conflicts really related to their usage of competing file structures? Or am I totally off-base here? -- Ben Pfaff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
