Renaming the RFE to something that might actually be worth implementing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
One major issue here is that setting up containers/chroots/whatever typically
requires root privileges. The build process is run as an unpriviledged user for
a reason. Yes, rpmbuild could drop privileges but not even handnig them out is
much more secure.
--
You are receiving this because you
I need to re-check why `-r` was not used, whether there is a good reason or if
it was just lost in the other breakage noise. Nevertheless that will only work
(if it works) for the symlinks we generate ourselves, not those produced by
upstream tools.
--
You are receiving this because you are
Another thought on the subject is that we could have a brp-script that turns
absolute links into relative ones.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@nim-nim
from `ln(1)`:
```
-r, --relative
create symbolic links relative to link location
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It is a lot harder to create relative symlinks reliably in spec files,
especially when part of the creating is given to manual packaging. (I
simplified the example, you can have multiple levels of directories). The whole
point of the FHS is not to have to worry about relative locations.
--
Yes, supporting bad packaging practises is not a reason to get into the
container business. However people might not realize the implications of
absolute symlinks in packages, it's something we could add a warning for.
--
You are receiving this because you are subscribed to this thread.
Reply
This is wrong way to create symlink, you should always create relative ones. In
that case it will work both during build and during runtime.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I the current way Go sources are organised, a "provides" is a directory
containing Go source files. And projects are renamed all the time so it is
common to alias previous names by symlinks (or http redirects in github)
so you have things like
```
/usr/share/gocode/src/oldname →
Do you have specific example where and how this should be used?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
10 matches
Mail list logo
