>> Clearly, ignoring such constraints is risky business (not like ignoring
>> "recommends" constraints), so you'd want to force the user to think hard
>> before doing so, and you'd only let her ignore specific constraints,
>> you might ask for confirmation before adding such an ignore-constraint
>> to the list of ignored constraints, and you might even query the user
>> every once in a while to make sure she still wants to keep those
>> ignore-constraints.
> Or simply not implement your request because we will never be happy to
> have misleading bug reports because the user has overriden a dependency
> that he shouldn't have.
I'd expect this info to be at the very forefront of the data provided by
`reportbug' and to elicit the same kind of responses as the "tainted"
bit of the kernel, i.e. "fix this dependency and then come back".
Even reportbug could refuse to send the report before you get rid of
this override rule.
> And we already have --force-depends for temporary workarounds.
[ Note that I've reassigned this but to `apt'. ]
I don't think any of the APT tools offers a "--force-depends".
And rightly so: it would be too blunt a tool, so a subsequent "aptitude
upgrade" would bite you right back, with a vengeance (at least that's
what happens if you use "dpkg --force-depends"). It seems difficult
to make it work differently: we need to store somewhere the list of
exceptions. Now, I'd be happy with just new arguments to aptitude
of the form --ignore-depend=<from>,<to>, and then store the list of
ignored dependencies somewhere in a file of mine, and then write
a little script around `aptitude' to pass those parameters. But I think
it'd be better for aptitude to manage that list directly. Among other
things, it would allow reportbug to check the list, and it would allow
aptitude to reassess the graph whenever the list is changed.
Stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
