Opened 13 years ago
Closed 6 years ago
#19 closed task (wontfix)
Provide CUBE replacement
| Reported by: | dmik | Owned by: | Yuri Dario |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | rpm | Version: | |
| Severity: | highest | Keywords: | |
| Cc: |
Description
CUBE has a very strange interface. I don't find it logical. This makes it very hard to understand and use. Besides, it has a lot of features not needed for playing with CONFIG.SYS and on the other hand it lacks some features, in particular:
- tracking of changes made by the package and automatic removal of them on uninstall, similar to %wps_object_delete_all.
- automatic conversion from Unix separators to DOS separators and resolving @unixroot in paths with the (()) operator (similar to our wps-object script again).
It will be relatively easy to take wps-object.cmd as a template and make a new one for the CONFIG.SYS purposes.
Change History (3)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Note also that automatic tracking of config.sys changes will makes it unnecessary to create backup copies of it (the thing that has been annoying almost every one since ever I think).
Though, we may still consider saving a copy of it before changing to /var/cache/rpm/config.sys/<package>/ -- just for cases if our script screws up. The obvious difference with usual saving it as a ton of c:\config.sys.NNN files is that it doesn't create a mess in the root drive right in front of the user's eyes.
comment:3 Changed 6 years ago by
| Resolution: | → wontfix |
|---|---|
| Severity: | → highest |
| Status: | new → closed |
as we have a lot rpm macros dealing with path and the like, I find cube is ok here. Investing time in a tool whic runs makes no sense to me. So I close it now after 7 years of being open :)
The most difficult thing seems to be working with PATH-like variables but we already have good and well debugged code for that in gccenv.cmd from the recent GCC 4 archives.