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