Bug 34400 - ucs_registerLDAPextension blindly removes files
ucs_registerLDAPextension blindly removes files
Status: RESOLVED WONTFIX
Product: UCS extended documentation
Classification: Unclassified
Component: Developer documentation
unspecified
All Linux
: P5 normal (vote)
: ---
Assigned To: Docu maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-26 13:49 CET by Philipp Hahn
Modified: 2024-04-17 13:16 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2014-03-26 13:49:32 CET
The Developers Guide only mentions "/path/to/some-{acl,schema,module,hook}" but don't recommends any sensible default.
If a naive developer uses the previously well known paths like /usr/share/pyshared/univention/admin/{handlers,hooks.d,syntax.d}/ and then removes those extensions again, the listener module removes the symlinks in /usr/lib/pymodules/python2.6//univention/admin/... which sometimes breaks UDM: Required syntaxes are no longer found and UDM-CLI-server refused to start, which manifests in "udm" not returning for a very long time.

Some combination of the following would be nice:
1. Warn about using the old paths.
2. Give a recommendation for /usr/share/$my_package_name/extendsion... or something similar.
3. Fix the listener to not delete links not created by itself, that is: refuse to delete links owned by packages / pysupport.
Comment 1 Arvid Requate univentionstaff 2014-03-28 17:27:53 CET
> 3. Fix the listener to not delete links not created by itself, that is: refuse to delete links owned by packages / pysupport.

A dpkg check was in the first version but flexibility was the argument to skip this at that time. You are right, we should re-think this point.
Comment 2 Nico Gulden univentionstaff 2024-04-17 13:16:24 CEST
This bug hasn't seen any update for several years. I close it.

If you still see a need for it, you can reopen the bug. Please add an argumentation about why it's important to take care of it.