11:51 p.m.
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(a)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.566...
12:31 a.m.
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,
https://access.redhat.com/support/cases/#/case/01326479
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(a)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.566...
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
7:35 a.m.
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/Guidelin...
[...]
Your package should own all of the files that are installed as part of
the %install process.
[...]
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:40 a.m.
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
10:35 a.m.
On Thu, Apr 23, 2015 at 8:10 PM, Ralf Corsepius <rc040203(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
3:17 a.m.
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(a)gmail.com> wrote:
On Thu, Apr 23, 2015 at 8:10 PM, Ralf Corsepius <rc040203(a)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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
>
8:47 a.m.
On 28 April 2015 at 09:17, John Dodson <johnd(a)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.
7:07 a.m.
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(a)gmail.com> wrote:
On 28 April 2015 at 09:17, John Dodson
<johnd(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
3256
days inactive
3288
days old
packaging@lists.fedoraproject.org
7 comments
6 participants
participants (6)
-
Deepu K S -
Dominik 'Rathann' Mierzejewski -
John Dodson -
Jonathan Underwood -
Ralf Corsepius -
Vít Ondruch