rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning. But now I've hit a review where the packager thinks an absolute symlink is appropriate and I'm not sure whether it's really an issue. The guidelines are silent on the subject; the only mention I see of it is in the mono guidelines, which say:
---- Mono installs binaries in /usr/lib/<package>/bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour). ----
That statement is somewhat confusing; is generating the error correct behavior? Is the symlink supposed to be fixed up or not? And does this apply in general to non-mono packages?
- J<
Jason L Tibbitts III wrote:
rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning. But now I've hit a review where the packager thinks an absolute symlink is appropriate and I'm not sure whether it's really an issue.
That's why rpmlint issues only a warning. IMO, it doesn't matter that much one way or the other as long as it still "just works".
Mono installs binaries in /usr/lib/<package>/bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour).
An error? I thought rpmlint only issues a warning for this?
-- Rex
Hi,
Mono installs binaries in /usr/lib/<package>/bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour).
An error? I thought rpmlint only issues a warning for this?
The problem is not so much the binary being in lib, but that it's not an ELF binary. That said, bins in lib shouldn't happen really...
TTFN
Paul
PFJ wrote:
Mono installs binaries in /usr/lib/<package>/bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour).
An error? I thought rpmlint only issues a warning for this?
The problem is not so much the binary being in lib, but that it's not an ELF binary.
And that's a problem because?
-- Rex
Hi,
An error? I thought rpmlint only issues a warning for this?
The problem is not so much the binary being in lib, but that it's not an ELF binary.
And that's a problem because?
Um, dunno, but rpmlint really does moan a lot with mono packages...
TTFN
Paul
PFJ wrote:
An error? I thought rpmlint only issues a warning for this?
The problem is not so much the binary being in lib, but that it's not an ELF binary.
And that's a problem because?
Um, dunno, but rpmlint really does moan a lot with mono packages...
So, lesson learned: don't blindly follow rpmlint?
-- Rex
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> That's why rpmlint issues only a warning. IMO, it doesn't matter RD> that much one way or the other as long as it still "just works".
What rpmlint chooses as a warning and what it chooses as an error seem to be arbitrary and not generally useful for predicting how significant the issues are. That is why I ask here.
- J<
Jason L Tibbitts III wrote:
"RD" == Rex Dieter rdieter@math.unl.edu writes:
RD> That's why rpmlint issues only a warning. IMO, it doesn't matter RD> that much one way or the other as long as it still "just works".
What rpmlint chooses as a warning and what it chooses as an error seem to be arbitrary and not generally useful for predicting how significant the issues are. That is why I ask here.
If we're speaking in "general", then consider rpmlint errors to be serious that deserve attention, and rpmlint warnings to be less serious and well, you get the idea.
-- Rex
On Tue, 2006-08-22 at 09:29 -0500, Rex Dieter wrote:
Jason L Tibbitts III wrote:
> "RD" == Rex Dieter rdieter@math.unl.edu writes:
What rpmlint chooses as a warning and what it chooses as an error seem to be arbitrary and not generally useful for predicting how significant the issues are. That is why I ask here.
If we're speaking in "general", then consider rpmlint errors to be serious that deserve attention, and rpmlint warnings to be less serious and well, you get the idea.
That's correct, with the addition that there are some checks that generally produce more false positives than others and aren't currently/cannot be done too robustly; in those cases I nowadays personally tend to make messages for new checks warnings even though the actual thing complained about might be a severe error if it's not a false positive.
There's also quite a bit of historical baggage whose error/warning classification rationale is unknown to me, and may no longer be quite optimal as upstream rpmlint is no longer Mandriva specific.
On Mon, Aug 21, 2006 at 11:21:41PM -0500, Jason L Tibbitts III wrote:
rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning.
what is the rationale behind preferring relative to absolute symlinks (unless relative means in the same folder)? I would even prefer it the other way around to avoid breakage.
But now I've hit a review where the packager thinks an absolute symlink is appropriate and I'm not sure whether it's really an issue. The guidelines are silent on the subject; the only mention I see of it is in the mono guidelines, which say:
Mono installs binaries in /usr/lib/<package>/bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour).
That statement is somewhat confusing; is generating the error correct behavior? Is the symlink supposed to be fixed up or not? And does this apply in general to non-mono packages?
- J<
Axel Thimm wrote:
On Mon, Aug 21, 2006 at 11:21:41PM -0500, Jason L Tibbitts III wrote:
rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning.
what is the rationale behind preferring relative to absolute symlinks (unless relative means in the same folder)? I would even prefer it the other way around to avoid breakage.
depends on your definition of breakage, whether the package is relocatable (not that we worry too much about that), whether the target of the symlink is in *this* pkg, etc... (:
-- Rex
On Tue, Aug 22, 2006 at 09:48:31AM -0500, Rex Dieter wrote:
Axel Thimm wrote:
On Mon, Aug 21, 2006 at 11:21:41PM -0500, Jason L Tibbitts III wrote:
rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning.
what is the rationale behind preferring relative to absolute symlinks (unless relative means in the same folder)? I would even prefer it the other way around to avoid breakage.
depends on your definition of breakage, whether the package is relocatable (not that we worry too much about that), whether the target of the symlink is in *this* pkg, etc... (:
Dangling symlinks break with relative and absolute links, but relative symlinks break whenever "folder/.." != ".", which is the case for symlinked folders.
Example: Suppose you'd like to have /var/mail/foo link to /var/bar and do that with ../bar, you'll end up at /var/spool/bar instead.
Symlinks in the filesystem as shipped are admittedly scarce, but it happens quite often to me that my system partition explodes and I need to move something over to a data partition symlinking it back. That would break relative symlinks, too.
Relative symlinks w/o "..", e.g. starting in the same folder, don't break, though.
On Mon, 2006-08-21 at 23:21 -0500, Jason L Tibbitts III wrote:
rpmlint spits symlink-should-be-relative warnings when it sees an absolute symlink, and generally folks have fixed things up when presented with the warning. But now I've hit a review where the packager thinks an absolute symlink is appropriate and I'm not sure whether it's really an issue.
Here's rpmlint's reasoning: 'Absolute symlinks are problematic eg. when working with chroot environments.'
I don't know that this is a blocker (the symlinks will work within the chroot environment but trying to access the symlinks from outside the chroot will do the wrong thing [access the system file rather than the one inside the chroot.])
So what's the package and what's the reasoning? If the package can be broken with relative symlinks but absolute symlinks work 100% then that would swing the balance towards using absolute symlinks. If it really boils down to the packager thinking his application is special then I think rpmlint is right in this case.
The guidelines are silent on the subject; the only mention I see of it is in the mono guidelines, which say:
Mono installs binaries in /usr/lib/<package>/bin with symlinks back to /usr/bin. rpmlint is not happy with this and generates an error (which is the correct behaviour).
IIRC, PFJ ran across an rpmlint warning here that isn't about symlinks but about Mono applications installing to /usr/lib/<package>/bin. I think the wording needs to be changed here too, as last I looked, the "symlinks back to /usr/bin" are actually wrapper scripts in %{_bindir} pointing to the program file in %{_libdir}/<package>/bin/<program>.
-Toshio
On Tue, Aug 22, 2006 at 08:04:16AM -0700, Toshio Kuratomi wrote:
Here's rpmlint's reasoning: 'Absolute symlinks are problematic eg. when working with chroot environments.'
In that sense every symlink is danergerous including relative ones: if it contains too many ".." you'll end up outside the chroot anyway if accessed from outside. If accessed from inside the chroot, absolute paths are even securer when being root.
Chroots (with external access, e.g. not within) aren't used by package consumers, but package builders and testers.
On Tue, 2006-08-22 at 17:10 +0200, Axel Thimm wrote:
On Tue, Aug 22, 2006 at 08:04:16AM -0700, Toshio Kuratomi wrote:
Here's rpmlint's reasoning: 'Absolute symlinks are problematic eg. when working with chroot environments.'
In that sense every symlink is danergerous including relative ones: if it contains too many ".." you'll end up outside the chroot anyway if accessed from outside.
That supposes that the symlink is referencing something above where the root directory should be. If it happens when the path is the same as where the package is meant to install, then I'd consider it a bug in packaging (ie: if you packaged a symlink, /usr/bin/ifconfig, it shouldn't point to ../../../../../sbin/ifconfig; it should point to ../../sbin/ifconfig).
If it happens with the path changed, (You install the previous package with --relocate /usr/bin=/bin) I'm inclined to say that's unsupported behaviour anyway.
If accessed from inside the chroot, absolute paths are even securer when being root.
More secure?
Chroots (with external access, e.g. not within) aren't used by package consumers, but package builders and testers.
This is incorrect. We often use chroots for building and testing packages here in Fedora but chroots are a much more general purpose tool.
I think relative symlinks and chroots are most important with configuration files where an administrator will try to edit the file from outside the chroot. There can be a world of difference between $CHROOT/root/resolv.conf => ../etc/resolv.conf and $CHROOT/root/resolv.conf => /etc/resolv.conf
-Toshio
On Tue, Aug 22, 2006 at 09:56:28AM -0700, Toshio Kuratomi wrote:
If accessed from inside the chroot, absolute paths are even securer when being root.
More secure?
Yes, you can't escape a chroot using absolute paths, almost every chroot exploit uses ".." once too many.
"TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> So what's the package and what's the reasoning?
The package is eclipse-subclipse, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191017
The reasoning is that the Core eclipse packages all do things this way and it isn't a problem there. Yes, that doesn't get a whole lot of traction with me given the general state of Core, but rather than just say that I figure I'd get some idea of just why the rpmlint complaint is there.
- J<
On Tue, 2006-08-22 at 11:15 -0500, Jason L Tibbitts III wrote:
"TK" == Toshio Kuratomi a.badger@gmail.com writes:
TK> So what's the package and what's the reasoning?
The package is eclipse-subclipse, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191017
The reasoning is that the Core eclipse packages all do things this way and it isn't a problem there. Yes, that doesn't get a whole lot of traction with me given the general state of Core, but rather than just say that I figure I'd get some idea of just why the rpmlint complaint is there.
Well, they aren't configuration files that the admin would want to edit. And Axel has some good points so based on information so far, I'd say rpmlint should be ignored here.
Not sure what I think when configuration files are involved as I think Axel's points and mine would run smack dab into each other there. Guess we'll have to reevaluate if we run across a case where that occurs.
-Toshio
packaging@lists.fedoraproject.org
-
Axel Thimm -
Jason L Tibbitts III -
Paul F. Johnson -
Rex Dieter -
Toshio Kuratomi -
Ville Skyttä