11:23 a.m.
i'm not sure if this question is too package-specific for this list,
but i'll take my chances.
for the sake of building "openwrt" on my f8 system, i installed the
"sdcc" (small device c compiler) package. and yet, when i try to
build openwrt, i get:
...
Checking 'sdcc'... failed.
firmwarehotplug: firmwarehotplug requires the SDCC Cross Compiler (sdcc).
...
a quick check of the pre-built tarballs at sdcc.sourceforge.net
shows that the binaries have names like sdcc, sdcpp and so on. but
note the names in the fedora package as installed by yum:
$ rpm -ql sdcc | grep bin
/usr/bin/sdcc-as-gbz80
/usr/bin/sdcc-as-hc08
/usr/bin/sdcc-as-z80
/usr/bin/sdcc-aslink
/usr/bin/sdcc-asx8051
/usr/bin/sdcc-link-gbz80
/usr/bin/sdcc-link-hc08
/usr/bin/sdcc-link-z80
/usr/bin/sdcc-makebin
/usr/bin/sdcc-packihx
/usr/bin/sdcc-s51
/usr/bin/sdcc-savr
/usr/bin/sdcc-sdcc
...
note the additional "sdcc-" prefix that's clearly(?) been added for
the sake of fedora packaging. i'm not sure if this was done to avoid
some sort of name conflict, but it obviously causes the openwrt build
error.
is this kind of transformation relatively common? the build from
the sdcc home page itself uses the regular names, so why is the fedora
packaging rewriting those? does this happen often?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
11:55 a.m.
On Sun, 2008-03-16 at 12:23 -0400, Robert P. J. Day wrote:
i'm not sure if this question is too package-specific for this
list,
but i'll take my chances.
for the sake of building "openwrt" on my f8 system, i installed the
"sdcc" (small device c compiler) package. and yet, when i try to
build openwrt, i get:
...
Checking 'sdcc'... failed.
firmwarehotplug: firmwarehotplug requires the SDCC Cross Compiler (sdcc).
...
a quick check of the pre-built tarballs at sdcc.sourceforge.net
shows that the binaries have names like sdcc, sdcpp and so on. but
note the names in the fedora package as installed by yum:
$ rpm -ql sdcc | grep bin
/usr/bin/sdcc-as-gbz80
/usr/bin/sdcc-as-hc08
/usr/bin/sdcc-as-z80
/usr/bin/sdcc-aslink
/usr/bin/sdcc-asx8051
/usr/bin/sdcc-link-gbz80
/usr/bin/sdcc-link-hc08
/usr/bin/sdcc-link-z80
/usr/bin/sdcc-makebin
/usr/bin/sdcc-packihx
/usr/bin/sdcc-s51
/usr/bin/sdcc-savr
/usr/bin/sdcc-sdcc
...
note the additional "sdcc-" prefix that's clearly(?) been added for
the sake of fedora packaging. i'm not sure if this was done to avoid
some sort of name conflict, but it obviously causes the openwrt build
error.
I can't comment about this particular case, but ...
is this kind of transformation relatively common?
Not in
Fedora and not necessarily on Linux, in general practice,
however: yes.
It can very often be found on non-linux OS when a tool's name would
clash with "native" tools's names (e.g. make -> gmake).
the build from
the sdcc home page itself uses the regular names, so why is the fedora
packaging rewriting those?
To avoid potential name clashes with other tools.
Things like aslink, makebin are simply too risky (rsp. their names are
unfortunately chosen by sdcc's upstream).
does this happen often?
No, only when necessary.
Ralf
12:35 p.m.
On Sun, 2008-03-16 at 12:23 -0400, Robert P. J. Day wrote:
is this kind of transformation relatively common? the build from
the sdcc home page itself uses the regular names, so why is the fedora
packaging rewriting those? does this happen often?
Its not common, nor is it mandated by the packaging guidelines, except
in cases of binary namespace conflicts. I think it would be worthwhile
to ask the sdcc maintainer what the reasoning is for this.
~spot
1:56 p.m.
On Sun, 16 Mar 2008, Tom "spot" Callaway wrote:
On Sun, 2008-03-16 at 12:23 -0400, Robert P. J. Day wrote:
> is this kind of transformation relatively common? the build
> from the sdcc home page itself uses the regular names, so why is
> the fedora packaging rewriting those? does this happen often?
Its not common, nor is it mandated by the packaging guidelines,
except in cases of binary namespace conflicts. I think it would be
worthwhile to ask the sdcc maintainer what the reasoning is for
this.
okeley dokeley. thanks.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
12:37 p.m.
>>>> "RPJD" == Robert P J Day
<rpjday(a)crashcourse.ca> writes:
RPJD> is this kind of transformation relatively common?
Yes, it is. See http://fedoraproject.org/wiki/Packaging/Conflicts
We don't generally want packages which conflict because they include
the same binaries; when some package contains any files which are
generically named and located in standard directories. Renaming or
relocation is the standard solution.
Dealing with this situation in a package that depends on things which
have been renamed isn't usually too difficult, although in this case I
don't know what the simplest solution is. One almost wishes for a
directory containing symlinks that you could add to the head of $PATH.
- J<
1:25 p.m.
Jason L Tibbitts III wrote:
>>>>> "RPJD" == Robert P J Day
<rpjday(a)crashcourse.ca> writes:
RPJD> is this kind of transformation relatively common?
Yes, it is. See http://fedoraproject.org/wiki/Packaging/Conflicts
We don't generally want packages which conflict because they include
the same binaries; when some package contains any files which are
generically named and located in standard directories. Renaming or
relocation is the standard solution.
Dealing with this situation in a package that depends on things which
have been renamed isn't usually too difficult, although in this case I
don't know what the simplest solution is. One almost wishes for a
directory containing symlinks that you could add to the head of $PATH.
And such a directory is a standard part of the Fedora sdcc package:
rpm -ql sdcc
<snip>
/usr/libexec/sdcc/as-gbz80
/usr/libexec/sdcc/as-hc08
/usr/libexec/sdcc/as-z80
/usr/libexec/sdcc/aslink
/usr/libexec/sdcc/asx8051
/usr/libexec/sdcc/link-gbz80
/usr/libexec/sdcc/link-hc08
/usr/libexec/sdcc/link-z80
/usr/libexec/sdcc/makebin
/usr/libexec/sdcc/packihx
/usr/libexec/sdcc/s51
/usr/libexec/sdcc/savr
/usr/libexec/sdcc/sdcc
/usr/libexec/sdcc/sdcclib
/usr/libexec/sdcc/sdcdb
/usr/libexec/sdcc/sdcpp
/usr/libexec/sdcc/shc08
/usr/libexec/sdcc/sz80
/usr/share/doc/sdcc-2.6.0
/usr/share/doc/sdcc-2.6.0/INSTALL.txt
/usr/share/doc/sdcc-2.6.0/README.fedora
<snip>
So the solution is to:
1) rtfm, aka README.fedora, where this is described
2) do "export PATH=/usr/libexec/sdcc:$PATH" before trying to build
openwrt and / or add this to your .bashrc
Regards,
Hans
2:24 p.m.
On Sun, 16 Mar 2008, Hans de Goede wrote:
Jason L Tibbitts III wrote:
> > > > > > "RPJD" == Robert P J Day
<rpjday(a)crashcourse.ca> writes:
>
> RPJD> is this kind of transformation relatively common?
>
> Yes, it is. See http://fedoraproject.org/wiki/Packaging/Conflicts
>
> We don't generally want packages which conflict because they
> include the same binaries; when some package contains any files
> which are generically named and located in standard directories.
> Renaming or relocation is the standard solution.
>
> Dealing with this situation in a package that depends on things
> which have been renamed isn't usually too difficult, although in
> this case I don't know what the simplest solution is. One almost
> wishes for a directory containing symlinks that you could add to
> the head of $PATH.
i assumed something like this was going on. but after a quick check,
i'm still curious:
1) who's the fedora packager for sdcc? "rpm -qi sdcc" doesn't seem to
refer to a particular person. it lists packager simply as "fedora
project."
2) is there a way to find out what package it was conflicting with,
and how? i imagine once i learn who the packager is, that part will
be easy to figure out.
And such a directory is a standard part of the Fedora sdcc package:
rpm -ql sdcc
<snip>
/usr/libexec/sdcc/as-gbz80
/usr/libexec/sdcc/as-hc08
/usr/libexec/sdcc/as-z80
/usr/libexec/sdcc/aslink
/usr/libexec/sdcc/asx8051
/usr/libexec/sdcc/link-gbz80
/usr/libexec/sdcc/link-hc08
/usr/libexec/sdcc/link-z80
/usr/libexec/sdcc/makebin
/usr/libexec/sdcc/packihx
/usr/libexec/sdcc/s51
/usr/libexec/sdcc/savr
/usr/libexec/sdcc/sdcc
/usr/libexec/sdcc/sdcclib
/usr/libexec/sdcc/sdcdb
/usr/libexec/sdcc/sdcpp
/usr/libexec/sdcc/shc08
/usr/libexec/sdcc/sz80
/usr/share/doc/sdcc-2.6.0
/usr/share/doc/sdcc-2.6.0/INSTALL.txt
/usr/share/doc/sdcc-2.6.0/README.fedora
<snip>
ah, i hadn't even noticed that. yes, that should solve the problem,
thanks.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
2:35 p.m.
On Sun March 16 2008, Robert P. J. Day wrote:
i assumed something like this was going on. but after a quick
check,
i'm still curious:
1) who's the fedora packager for sdcc? "rpm -qi sdcc" doesn't seem to
refer to a particular person. it lists packager simply as "fedora
project."
You find this information in the Fedora Package Database:
https://admin.fedoraproject.org/pkgdb/packages/name/sdcc
Or the changelog of the rpm can give you some hints (use --changelog in your
query).
Regards,
Till
3:15 p.m.
Robert P. J. Day wrote:
2) is there a way to find out what package it was conflicting with,
and how? i imagine once i learn who the packager is, that part will
be easy to figure out.
I'm not the packager, but I have reviewed the package when it first hit Fedora,
there were no actual conflicts that I know if, its just that names like
"as-z80" and even more so makebin are just too generic. So we (Trond, the
packager and me) decided it would be better to avoid any possible conflicts
from the start.
Regards,
Hans
5886
days inactive
5886
days old
packaging@lists.fedoraproject.org
8 comments
6 participants
participants (6)
-
Hans de Goede -
Jason L Tibbitts III -
Ralf Corsepius -
Robert P. J. Day -
Till Maas -
Tom Callaway