-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please remove the "absolute symlink" warnings #2419
Comments
Just for the context, I am working on project to remove bundled assets in generated RDoc documentation: https://fedorapeople.org/cgit/vondruch/public_git/darkfish.git/ This is going to replace the assets with symlinks and I think the absolute symlinks is the right choice, because it allows users to copy the documentation around while keep it working. But in turn, that means that every rubygem-*-doc package will spit tens or more symlink warnings:
I don't think RPM should judge this. |
Hmm, this looks like a good candidate for a treatment similar to #2383, i.e. suppressing these warnings into a single one with a count. |
Absolute symlinks are downright dangerous in combination with chrooted content. The absolute link okay inside the chroot of course, but have you never, ever looked at eg /var/lib/mock/ stuff without chrooting into it? The reason rpm complains about absolute symlinks is that they are problematic (for the user!) in the rpm context where chrooted installations is bread-and-butter daily business. |
@dmnks , in reality these warnings are not the same because the filename differs. The %patch case is similar: it really should print out the line number + line, it was only made the way it is to allow us to squeeze it into 4.18. We shouldn't get into a habit of producing bad warning messages for the purpose of suppressing them 😆 |
You mean that outside of chroot, they point to system locations? What is wrong with it? That is fine by me and if I am "lucky", they might point to useful location. Or is the problem that some might edit e.g. system configuration instead of the chroot configuration? I don't see this as a problem. Again, if this is so problematic, then this should be probably reflected in Fedora guidelines, but not judged by RPM. RPM on itself has not any use of chroot. |
Rpm chroot installations and the associated problems (yes, content pointing to system locations with a non-trivial risk of breaking things badly) with absolute links are not specific to Fedora in any way. The warning is there for a reason and the way to avoid it is to convert to relative links, whether automatically as suggested in #668 or manually. |
Then could you please do me a favor and propose update to Fedora packaging guidelines? I won't do it myself, because I disagree with this and consider the current guidelines to be correct. But they should be in line with what RPM thinks if RPM changes its mind. |
Or this should be configurable and Fedora should be able to choose to configure RPM in a way that it is consistent with their guidelines. |
Sorry but I don't go around lecturing distros what they should or shouldn't do. That's what the warning is for. |
The guideline is in Fedora at least as long as the Git history goes, which is 5 years. The warning landed in RPM ~3.5 years ago. So if the RPM was pushed into Fedora by the RPM team, it would be just fair to make sure that the guidelines are aligned with what RPM does. In this case, RPM is certainly lecturing distros and it would be just fair if RPM team would taken the additional step and made sure the distros guideline does not result in warnings. |
Yes, like I said, the warning is a piece of education from the upstream. I see no reason why distros should make a special statement about this whatsoever. If you feel so, then you go file a request about it. By all means. |
I have read the #668, but I disagree with the #680. Both relative as well as absolute symlinks has their own issue in the build root and elsewhere. There is not clear winner. Neither Fedora packaging guidelines choose sides. The warnings are just noise. Please remove them.
The text was updated successfully, but these errors were encountered: