Custom Query (344 matches)
Results (91 - 93 of 344)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#263 | wontfix | Provide a GUI widget reminding about a reboot | ||
Description |
There are #261 and #262 which should make RPM forbid any package install/update/remove operation if an application restart or a system reboot is pending. We should also add a nice GUI widget (e.g. the one in XCenter) that will remind the user to close the required applications or to reboot in some reasonable intervals if it's not done immediately when executing the respective YUM or RPM command that caused such a pending state. Note that this GUI widget should be RPM frontend agnostic. I.e. it should work after both using YUM from the command line or ANPM or any other RPM frontend. That said, YUM or ANPM should of course provide their own UI for performing the requested action immediately, but if the user refuses and closes YUM/ANPM before performing it, this GUI widget should kick in. |
|||
#259 | wontfix | Finer granularity for OS/2 DLL dependency generator | ||
Description |
Currently, the OS/2 DLL dependency generator detects only DLL names for Requires/Provides? but not the functions which are imported or exported. However, sometimes the import/export list of a DLL changes w/o changing its name. The most frequent case is addition of new exports.
Imagine a situation: LIB.DLL gets a new export FOO. This lib is released to a beta repository (not available for everyone) with Note that this mostly applies to cases when new exports are added to a DLL because if there is a change or removal, the DLL becomes non-backward compatible which requires to change its name (and when the name changes, the dependency generator will update the dependency forcing the user to update the DLL as well). A proposed solution is to increase granularity of the Provides/Requires? records by adding not only the DLL name but the export name as well — using the parenthesis notation just like other generators (e.g. perl, python, pkg-config etc) do. So in the above imaginary case, the generator should add the following for the LIB.DLL RPM: Provides: LIB.DLL Provides: LIB.DLL(FOO) And the following for the APP RPM: Requires: LIB.DLL(FOO)
instead of just This way, any potential problems related to export/import mismatches will be solved automatically and for all possible combination of package dependencies. This is relatively easy to implement as all imports and exports are collected in the respective sections of EXE and DLL files in binary form (so it's fast to extract this information). The only potential problem I see is C++ DLLs which export huge amounts of C++ symbols (i.e. the Qt DLLs contain thousands of exports). But it doesn't sound too serious per se as RPM is designed to handle thousands of dependencies. |
|||
#258 | duplicate | Build an updated QtNet4.dll package | ||
Description |
Per discussion in this thread, http://www.os2world.com/forum/index.php/topic,1480.0.html seems that some programs require a newer QtNet4.dll that Silvan built a couple of years back. Perhaps this can be packaged. |