Hi list, I'm new to this list but have had a hard time convincing redhat people that broken symlinks are bad! (I'm not going to bother trying to convice you ;-)
What I would like to do is get a "package" to take responsibility for the many broken symlinks out there. So that at least a broken symlink can be assigned to a specific package the owner of which thinks (sic) that the symlink is "required" from his/her perspective. (I won't say that the code should be more intelligent & create a symlink if it is really necessary & remove it when it's broken as that would expect too much)
Please see,
https://access.redhat.com/support/cases/#/case/01326479
for more detail.
Generally many packages create symlinks, but don't "own them", I'd like to change that. eg. kernel packagages if the source is not installed.
Try, find / -type l -exec file "{}" ; |grep broken
Cheers
johnd
John Dodson | Bosch Research Engineering & Computing Facility Manager, | Network Manager Medical Sciences, Electrical/Electronics/Control | Telecommunications Engineer Physiology/School of Medical Sciences
The University of Sydney Rm N252,Anderson Stuart Building (F13) Eastern Avenue, The University of Sydney|NSW|2006|Australia. T +61 2 9351 5246 | F +61 2 9351 2058 | M +61 4 1459 7557 E johnd@physiol.usyd.edu.au | W http://www.physiol.usyd.edu.au/johnd ABN:15 211 513 464 CRICOS Number: 00026A
I'd rather be on OTI... http://www.bio.usyd.edu.au/OTI https://www.google.com.au/maps/place/One+Tree+Island,+Queensland/@-23.566657...
Dne 23.4.2015 v 06:51 John Dodson napsal(a):
Hi list, I'm new to this list but have had a hard time convincing redhat people that broken symlinks are bad! (I'm not going to bother trying to convice you ;-)
What I would like to do is get a "package" to take responsibility for the many broken symlinks out there. So that at least a broken symlink can be assigned to a specific package the owner of which thinks (sic) that the symlink is "required" from his/her perspective. (I won't say that the code should be more intelligent & create a symlink if it is really necessary & remove it when it's broken as that would expect too much)
Please see,
The BZ https://bugzilla.redhat.com/show_bug.cgi?id=1185918 will be probably better reference. Not everybody has access to RH's customer portal.
Vít
for more detail.
Generally many packages create symlinks, but don't "own them", I'd like to change that. eg. kernel packagages if the source is not installed.
Try, find / -type l -exec file "{}" ; |grep broken
Cheers
johnd
John Dodson | Bosch Research Engineering & Computing Facility Manager, | Network Manager Medical Sciences, Electrical/Electronics/Control | Telecommunications Engineer Physiology/School of Medical Sciences
The University of Sydney Rm N252,Anderson Stuart Building (F13) Eastern Avenue, The University of Sydney|NSW|2006|Australia. T +61 2 9351 5246 | F +61 2 9351 2058 | M +61 4 1459 7557 E johnd@physiol.usyd.edu.au | W http://www.physiol.usyd.edu.au/johnd ABN:15 211 513 464 CRICOS Number: 00026A
I'd rather be on OTI... http://www.bio.usyd.edu.au/OTI https://www.google.com.au/maps/place/One+Tree+Island,+Queensland/@-23.566657...
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Thursday, 23 April 2015 at 06:51, John Dodson wrote:
Hi list, I'm new to this list but have had a hard time convincing redhat people that broken symlinks are bad! (I'm not going to bother trying to convice you ;-)
I believe kernel package maintainers have more pressing concerns than a few dangling links, but if you sent a patch that fixes the issue, they might just take it.
What I would like to do is get a "package" to take responsibility for the many broken symlinks out there. So that at least a broken symlink can be assigned to a specific package the owner of which thinks (sic) that the symlink is "required" from his/her perspective. (I won't say that the code should be more intelligent & create a symlink if it is really necessary & remove it when it's broken as that would expect too much)
Please see,
https://access.redhat.com/support/cases/#/case/01326479
for more detail.
Generally many packages create symlinks, but don't "own them", I'd like to change that. eg. kernel packagages if the source is not installed.
Try, find / -type l -exec file "{}" ; |grep broken
Judging by https://bugzilla.redhat.com/show_bug.cgi?id=1185918 , they are not actually unowned at least in the kernel package. You could send a patch to move them to kernel-devel subpackage, but you need to ensure that you don't cause any breakage between package upgrades.
Are there any other packages that create broken symlinks but don't have them listed in their %files sections? That would be against the current packaging guidelines.
I guess you'd like to add a rule saying that all symlinks installed by a package must point at existing files (either from the same package or from one of the dependencies). Arguably, such a rule exists already: https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#... [...] Your package should own all of the files that are installed as part of the %install process. [...]
Regards, Dominik
On 04/23/2015 02:35 PM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 23 April 2015 at 06:51, John Dodson wrote:
Are there any other packages that create broken symlinks but don't have them listed in their %files sections? That would be against the current packaging guidelines.
Plenty.
Many systemd packages and packages using alternatives are amongst them: # rpm -qf /etc/systemd/system/* # rpm -qf /etc/alternatives/*
I guess, there are many more.
Ralf
On Thu, Apr 23, 2015 at 8:10 PM, Ralf Corsepius rc040203@freenet.de wrote:
On 04/23/2015 02:35 PM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 23 April 2015 at 06:51, John Dodson wrote:
Are there any other packages that create broken symlinks but don't have
them listed in their %files sections? That would be against the current packaging guidelines.
Plenty.
Many systemd packages and packages using alternatives are amongst them: # rpm -qf /etc/systemd/system/* # rpm -qf /etc/alternatives/*
I guess, there are many more.
Yes, check for dangling links gives long output. # symlinks -r / | grep -i dangling
Listing a few below; ======================== dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libasan.a -> ../../../i686-redhat-linux/4.8.3/libasan.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libatomic.a -> ../../../i686-redhat-linux/4.8.3/libatomic.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libgcc_s.so -> /lib/libgcc_s.so.1 dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libgomp.so -> ../../../../libgomp.so.1.0.0 dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libitm.a -> ../../../i686-redhat-linux/4.8.3/libitm.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libmudflap.a -> ../../../i686-redhat-linux/4.8.3/libmudflap.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libmudflapth.a -> ../../../i686-redhat-linux/4.8.3/libmudflapth.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libquadmath.a -> ../../../i686-redhat-linux/4.8.3/libquadmath.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libstdc++.a -> ../../../i686-redhat-linux/4.8.3/libstdc++.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libstdc++.so -> ../../../../libstdc++.so.6.0.19 dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libsupc++.a -> ../../../i686-redhat-linux/4.8.3/libsupc++.a dangling: /usr/lib/modules/3.19.4-100.fc20.x86_64/build -> /usr/src/kernels/3.19.4-100.fc20.x86_64 dangling: /usr/lib/modules/3.19.4-100.fc20.x86_64/source -> build =========================
In above, the symlink is in gcc package, but the file comes with static library package. (for eg: libatomic-static.i686)
-deepuks
Ralf
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Sorry - I've been offline for a bit.
Thanks Deepu & others. I think the dangling symlink problem is now in the right place & will probably get some attention by at least being brought up & thought about. I'm sure the Kernel people will deal with it when they can & they will be moved to the -devel package appropriately.
Cheers
johnd
Deepu K S deepuks86@gmail.com wrote: On Thu, Apr 23, 2015 at 8:10 PM, Ralf Corsepius rc040203@freenet.de wrote:
On 04/23/2015 02:35 PM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 23 April 2015 at 06:51, John Dodson wrote:
Are there any other packages that create broken symlinks but don't have
them listed in their %files sections? That would be against the current packaging guidelines.
Plenty.
Many systemd packages and packages using alternatives are amongst them: # rpm -qf /etc/systemd/system/* # rpm -qf /etc/alternatives/*
I guess, there are many more.
Yes, check for dangling links gives long output. # symlinks -r / | grep -i dangling
Listing a few below;
dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libasan.a -> ../../../i686-redhat-linux/4.8.3/libasan.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libatomic.a -> ../../../i686-redhat-linux/4.8.3/libatomic.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libgcc_s.so -> /lib/libgcc_s.so.1 dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libgomp.so -> ../../../../libgomp.so.1.0.0 dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libitm.a -> ../../../i686-redhat-linux/4.8.3/libitm.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libmudflap.a -> ../../../i686-redhat-linux/4.8.3/libmudflap.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libmudflapth.a -> ../../../i686-redhat-linux/4.8.3/libmudflapth.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libquadmath.a -> ../../../i686-redhat-linux/4.8.3/libquadmath.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libstdc++.a -> ../../../i686-redhat-linux/4.8.3/libstdc++.a dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libstdc++.so -> ../../../../libstdc++.so.6.0.19 dangling: /usr/lib/gcc/x86_64-redhat-linux/4.8.3/32/libsupc++.a -> ../../../i686-redhat-linux/4.8.3/libsupc++.a dangling: /usr/lib/modules/3.19.4-100.fc20.x86_64/build -> /usr/src/kernels/3.19.4-100.fc20.x86_64 dangling: /usr/lib/modules/3.19.4-100.fc20.x86_64/source -> build =========================
In above, the symlink is in gcc package, but the file comes with static library package. (for eg: libatomic-static.i686)
-deepuks
Ralf
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On 28 April 2015 at 09:17, John Dodson johnd@physiol.usyd.edu.au wrote:
Sorry - I've been offline for a bit.
Thanks Deepu & others. I think the dangling symlink problem is now in the right place & will probably get some attention by at least being brought up & thought about. I'm sure the Kernel people will deal with it when they can & they will be moved to the -devel package appropriately.
I think there'll only be more progress on the issue if someone proposes a packaging guideline draft along the lines of what Dominik proposed earlier in the thread.
Hello,
Sorry for the delay. I tried below change in kernel.spec and now with this patch, the build and source symlinks are moved into kernel-devel package.
This was been tested for Fedora 21 kernel-3.19.7-200 Source RPM : kernel-3.19.7-200.fc21.src.rpm
I request kernel package maintainers to please have look into it.
--- a/kernel-orig.spec 2015-05-08 03:06:43.000000000 +0530 +++ b/kernel.spec 2015-05-22 23:17:07.636035055 +0530 @@ -2252,8 +2252,6 @@ fi %dir /lib/modules\ %dir /lib/modules/%{KVERREL}%{?2:+%{2}}\ %dir /lib/modules/%{KVERREL}%{?2:+%{2}}/kernel\ -/lib/modules/%{KVERREL}%{?2:+%{2}}/build\ -/lib/modules/%{KVERREL}%{?2:+%{2}}/source\ /lib/modules/%{KVERREL}%{?2:+%{2}}/updates\ %ifarch %{vdso_arches}\ /lib/modules/%{KVERREL}%{?2:+%{2}}/vdso\ @@ -2263,6 +2261,8 @@ fi %{expand:%%files -f kernel-%{?2:%{2}-}modules.list %{?2:%{2}-}modules}\ %defattr(-,root,root)\ %{expand:%%files %{?2:%{2}-}devel}\ +/lib/modules/%{KVERREL}%{?2:+%{2}}/build\ +/lib/modules/%{KVERREL}%{?2:+%{2}}/source\ %defattr(-,root,root)\ /usr/src/kernels/%{KVERREL}%{?2:+%{2}}\ %{expand:%%files %{?2:%{2}-}modules-extra}\
Thanks and Regards, Deepu K S
On Tue, Apr 28, 2015 at 7:17 PM, Jonathan Underwood < jonathan.underwood@gmail.com> wrote:
On 28 April 2015 at 09:17, John Dodson johnd@physiol.usyd.edu.au wrote:
Sorry - I've been offline for a bit.
Thanks Deepu & others. I think the dangling symlink problem is now in the right place & will
probably
get some attention by at least being brought up & thought about. I'm sure the Kernel people will deal with it when they can & they will
be moved
to the -devel package appropriately.
I think there'll only be more progress on the issue if someone proposes a packaging guideline draft along the lines of what Dominik proposed earlier in the thread. -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
packaging@lists.fedoraproject.org
-
Deepu K S -
Dominik 'Rathann' Mierzejewski -
John Dodson -
Jonathan Underwood -
Ralf Corsepius -
Vít Ondruch