Richard Freeman pisze:
Bo Ørsted Andresen wrote:
On Wednesday 16 April 2008 10:15:16 Mateusz A. Mierzwiński wrote:
So why not to send on screen info about what to do rather then "ERROR"?
Please reread this entire thread. That's exactly what is being proposed.
I'd go one step further. Don't tell the user what to do - just do it
(when this is safe).
Maybe have a REPLACES="app-foo/bar" variable in ebuilds. That tells
the package manager that the new package supersedes the old one - any
version of the new package is considered higher in version than any
version of the old package. Any cases where the new package
overwrites files belonging to the old package are not detected as
collisions. If set to auto-clean the package manger unmerges the old
package after merging the new one. If the package manager sees the
old package in world it will act like the new package is in world.
Basically you treat it like an upgrade.
This isn't always desirable, and in those cases you wouldn't use this
functionality.
Having an ebuild output a list of steps telling the user how to work
around a package manager limitation is really a non-ideal solution.
If a defined set of steps will always fix the issue, why not just do
them?
And maybe have an option/FEATURE to disable this behavior, just as you
can disable auto-cleaning in portage. We don't tell users to manually
clean out old versions of software, so why tell them to manually
resolve other issues?
Again, I'm not proposing this as a fix to ALL blocks. However,
something like this could have made the mktemp mess a lot simpler.
There would have been no issues to end users if the new coreutils
silently collided with mktemp and triggered auto-removal of mktemp
when the upgrade was done.
This are good idea's. But i think about what You have written - when
this is safe. I think this could make some troubles...
--
gentoo-dev@lists.gentoo.org mailing list
