| Summary: | sfu.so dangling links | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Bit Twister <bittwister2> |
| Component: | RPM Packages | Assignee: | Buchan Milne test 2 <bgmilne> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | bgmilne, davidwhodgins |
| Version: | Cauldron | Keywords: | Junior_job, Triaged |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | samba-3.5.11-1.mga2.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Bit Twister
2011-12-02 01:18:27 CET
Bit Twister
2011-12-02 01:20:03 CET
Summary:
samba-3.5.11-1.mga2.src.rpm =>
2_alpha1: sfu.so dangling links Those links will be valid if samba-winbind is installed. The symlinks are in a directory owned by the samba-server package, while the files being linked to are in the samba-winbind package. The symlinks are only required if both packages are installed, however since neither package requires the other, so the order they are installed in cannot be guaranteed. The only way I can see to ensure the symlinks exist when needed, but are not created as dangling, is to have both packages check to see if the other is already installed, and only create the symlinks if this is true. CC:
(none) =>
davidwhodgins Hi, thanks for reporting this bug. Assigned to the package maintainer. Summary:
2_alpha1: sfu.so dangling links =>
sfu.so dangling links 1)I see no harm in a few dangling symlinks 2)I see no uncomplicated solution Feel free to provide a 100% tested patch, if it is under 6 lines of change to the spec file, I might consider it. Status:
NEW =>
RESOLVED (In reply to comment #3) > 1)I see no harm in a few dangling symlinks Heheheh, typical developer mentality. :-D Does not matter that system integrators have to ignore those links when testing. Same thing goes for the poor overworked Quality Assurance tester. Forget about all the paranoid System Administrators wondering if their disk or mount point has/is going bad. Paranoid users worried about malware infestation, they can learn to recognize the problem or write up problem reports you can pencil whip with wontfix solution. Why settle for a World Class Linux distribution. If user wants a polished product, they can buy support from someone like RedHat. I am sure Mageia Management does not care if there are some really small defects in their product. :) Seriously, I picked all package groups on a clean install. Should the samba-winbind package have been loaded along with samba-server? I really do not care about the problem. I am leaving Mandriva because of the same kind of developer attitudes I have encountered over there. Thought I would come over to Mageia to help make it a better product by being a User tester. I'll modify my link auditor script to ignore your broken links. > Does not matter that system integrators have to ignore those links when testing. Your bug report did not mention any use case which motivated effort to fix this correctly. Note that the only solutions mentioned so far are more difficult to get right, and will most likely have bugs that are difficult to test for. > If user wants a polished product, they can buy support from someone like RedHat. If they want one where every feature of a suite of software is bundled together, and cannot be used independently, maybe Red Hat is what they are after. > I am sure Mageia Management Magiea is a community distribution, there is no 'Management' per se. > Should the samba-winbind package have been loaded along with samba-server? In my opinion, no. Red Hat's opinion, and the opinion of the samba developers (some of which are employed by Red Hat) may be different. But really, let's stick to technical dicussion. If you can provide an idea on how you think this can be solved without too much complexity, without increasing the footprint excessively (samba is *huge* these days, and there are *many* *many* use cases without winbind), I will consider them. But again, you provided no use case besides "I don't like seeing dangling symlinks" for this bug. Note that your other two duplicate bugs are fixed in svn. |