8:38 p.m.
I was looking through the old review tickets and saw Ralf's submission
of i386-rtems4.7-binutils. I don't believe that's a good name, but I
can't really think of what it should be named. binutils-i386-rtems4.7
is one possibility, but then the gcc package would end up as
gcc-newlib-i386-rtems4.7 which isn't logically connected to the
binutils package.
How about a "cross" namespace: cross-target-utility would give us
cross-i386-rtems4.7-binutils and cross-i386-rtems4.7-gcc-newlib.
- J<
10:59 p.m.
On Thu, 2006-06-15 at 20:38 -0500, Jason L Tibbitts III wrote:
I was looking through the old review tickets and saw Ralf's
submission
of i386-rtems4.7-binutils. I don't believe that's a good name,
Why?
This name is the name being used for GNU crosstool toolchains for many
years (> a decade). It corresponds to the target canonicalization tuple
internally being used by binutils/gcc/gdb, and the autotools.
Also using $target as package prefix is convenient when browsing
repositories, because all packages will be sorted neighboring in
directory listings.
but I
can't really think of what it should be named. binutils-i386-rtems4.7
is one possibility, but then the gcc package would end up as
gcc-newlib-i386-rtems4.7 which isn't logically connected to the
binutils package.
How about a "cross" namespace: cross-target-utility would give us
cross-i386-rtems4.7-binutils and cross-i386-rtems4.7-gcc-newlib.
From my view: <target>-{binutils|gcc|gdb|libc|newlib}
Prefixing these packages with "cross" to me is meaningless, because it's
redundant.
Also remember: The applications inside are native (=Linux)applications,
it's only that they target "a foreign system".
Ralf
11:19 p.m.
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> Why?
What is "i386" and why does it have a subpackage of "rtems4.7"?
RC> This name is the name being used for GNU crosstool toolchains for
RC> many years (> a decade). It corresponds to the target
RC> canonicalization tuple internally being used by binutils/gcc/gdb,
RC> and the autotools.
So? We are free to make decisions for ourselves instead of blindly
using someone else's naming convention. If the name is completely
confusing (as it is to me) then surely we should talk about it before
just stuffing it into the repository. We have no guidelines for this
kind of thing, so it warrants discussion. This is the proper list for
such discussion, right?
RC> Prefixing these packages with "cross" to me is meaningless,
RC> because it's redundant.
There doesn't seem to be any other part of the package name that would
suggest such.
- J<
11:49 p.m.
On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> Why?
What is "i386" and why does it have a subpackage of "rtems4.7"?
RC> This name is the name being used for GNU crosstool toolchains for
RC> many years (> a decade). It corresponds to the target
RC> canonicalization tuple internally being used by binutils/gcc/gdb,
RC> and the autotools.
So?
Yes. Target canonicalization tuples are standardized (In particular in
binutils, GCC and gdb) and shared between *all* projects using
config.guess and config.sub (I.e. all package using the autotools).
We are free to make decisions for ourselves instead of blindly
using someone else's naming convention.
Yes, it's our freedom to waste time
on re- and over engineering parts
others have spend decades on.
A gcc cross compiler's components are called
<target>-<component>
You can even find traces of this in Fedora:
e.g.
/usr/bin/i386-redhat-linux-gcc
/usr/bin/i386-redhat-linux-c++
I.e. people will be looking for <target>-<tool>
If the name is completely
confusing (as it is to me) then surely we should talk about it before
just stuffing it into the repository.
Would packages be called
i386-cygwin-gcc
or
i386-redhat-gcc
i586-suse-gcc
sparc-sun-solaris2.8-gcc
be confusing to you?
IMO, they are self-explanatory.
Ralf
12:04 a.m.
Ralf Corsepius wrote:
On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote:
>>>>>> "RC" == Ralf Corsepius <rc040203(a)freenet.de>
writes:
> RC> Why?
>
> What is "i386" and why does it have a subpackage of "rtems4.7"?
>
> RC> This name is the name being used for GNU crosstool toolchains for
> RC> many years (> a decade). It corresponds to the target
> RC> canonicalization tuple internally being used by binutils/gcc/gdb,
> RC> and the autotools.
>
> So?
Yes. Target canonicalization tuples are standardized (In particular in
binutils, GCC and gdb) and shared between *all* projects using
config.guess and config.sub (I.e. all package using the autotools).
> We are free to make decisions for ourselves instead of blindly
> using someone else's naming convention.
Yes, it's our freedom to waste time on re- and over engineering parts
others have spend decades on.
A gcc cross compiler's components are called
<target>-<component>
You can even find traces of this in Fedora:
e.g.
/usr/bin/i386-redhat-linux-gcc
/usr/bin/i386-redhat-linux-c++
I.e. people will be looking for <target>-<tool>
> If the name is completely
> confusing (as it is to me) then surely we should talk about it before
> just stuffing it into the repository.
Would packages be called
i386-cygwin-gcc
or
i386-redhat-gcc
i586-suse-gcc
sparc-sun-solaris2.8-gcc
be confusing to you?
IMO, they are self-explanatory.
Why is the binary target name being used for the package name? That's
not intuitive to an end user at all IMHO.
I think confusing the binary target name with the actual package name is
a mistake.
gcc is gcc, not i386-redhat-linux-gcc
OpenSUSE uses cross-<arch>-gcc/binutils/whatever-version
debian looks like it uses gcc/binutils/whatever-<arch>-version
Personally I like the cross-prefix, its a lot more obvious to an end
user what the package is and is for, but thats just me.
Michael
1:26 a.m.
On Fri, 2006-06-16 at 17:04 +1200, Michael J. Knox wrote:
Ralf Corsepius wrote:
> On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote:
>>>>>>> "RC" == Ralf Corsepius <rc040203(a)freenet.de>
writes:
>> RC> Why?
>>
>> What is "i386" and why does it have a subpackage of
"rtems4.7"?
>>
>> RC> This name is the name being used for GNU crosstool toolchains for
>> RC> many years (> a decade). It corresponds to the target
>> RC> canonicalization tuple internally being used by binutils/gcc/gdb,
>> RC> and the autotools.
>>
>> So?
> Yes. Target canonicalization tuples are standardized (In particular in
> binutils, GCC and gdb) and shared between *all* projects using
> config.guess and config.sub (I.e. all package using the autotools).
>
>> We are free to make decisions for ourselves instead of blindly
>> using someone else's naming convention.
> Yes, it's our freedom to waste time on re- and over engineering parts
> others have spend decades on.
>
> A gcc cross compiler's components are called
> <target>-<component>
>
> You can even find traces of this in Fedora:
> e.g.
> /usr/bin/i386-redhat-linux-gcc
> /usr/bin/i386-redhat-linux-c++
>
> I.e. people will be looking for <target>-<tool>
>
>> If the name is completely
>> confusing (as it is to me) then surely we should talk about it before
>> just stuffing it into the repository.
> Would packages be called
> i386-cygwin-gcc
> or
> i386-redhat-gcc
> i586-suse-gcc
> sparc-sun-solaris2.8-gcc
>
> be confusing to you?
>
> IMO, they are self-explanatory.
Why is the binary target name being used for the package name? That's
not intuitive to an end user at all IMHO.
I think confusing the binary target name with the actual package name is
a mistake.
gcc is gcc, not i386-redhat-linux-gcc
Wrong. What you have installed is an
i386-redhat-linux-gcc rsp. a
x86-68-redhat-linux-gcc (more precisely, a GCC having been configured
for host=<arch>-redhat-linux). As this gcc also is the native gcc, it
also is being installed as "gcc", which justifies the package to be
called gcc.
OpenSUSE uses cross-<arch>-gcc/binutils/whatever-version
debian looks like it uses gcc/binutils/whatever-<arch>-version
What is the <whatever>? That's the essential part of it.
A "cross-i386-gcc" would be complete non-sense, because a cross tool
chain depends on the OS and several components more. An
i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or
a i386-redhat-gcc or a i386-suse-gcc.
I presume they are abbreviating and using <arch> as a synonym for
"<arch>-suse-linux".
... Debian ..., their packaging is the worst of all possible choices.
It's neither browsable, nor complete nor correct, nor current.
Basically looks like rotten packages to me.
Personally I like the cross-prefix, its a lot more obvious to an end
user what the package is and is for, but thats just me.
Everybody being used to cross tool chains, knows that the tools insided
are called <target>-<tools>.
Finally a different view on this issue:
A GNU cross toolchain consists of several packages which comes in
different, multiple incarnations.
Packaging-wise, this situation is not any different from packages which
can be built against different base infrastructures, say:
xorg-mydriver vs. xfree-mydriver
gnome-coolguitool vs. kde-coolguitool
perl-XXXX perl7-XXXX
or (Real world example)
Coin2-* vs. Inventor-*
Ralf
2:39 a.m.
Ralf Corsepius wrote:
> Why is the binary target name being used for the package name?
That's
> not intuitive to an end user at all IMHO.
>
> I think confusing the binary target name with the actual package name is
> a mistake.
>
> gcc is gcc, not i386-redhat-linux-gcc
>
Wrong. What you have installed is an i386-redhat-linux-gcc rsp. a
x86-68-redhat-linux-gcc (more precisely, a GCC having been configured
for host=<arch>-redhat-linux). As this gcc also is the native gcc, it
also is being installed as "gcc", which justifies the package to be
called gcc.
Ok fair enough.
> OpenSUSE uses cross-<arch>-gcc/binutils/whatever-version
> debian looks like it uses gcc/binutils/whatever-<arch>-version
>
What is the <whatever>? That's the essential part of it.
Its not <whatever> it was /whatever/ implying insert cross tool here.
A "cross-i386-gcc" would be complete non-sense, because a
cross tool
chain depends on the OS and several components more. An
i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or
a i386-redhat-gcc or a i386-suse-gcc.
Again, this is a packaging name, not a binary target. Packaged as
cross-arm-gcc for example, tells me straigh way what this package is.
However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy
binutils? A binutils addon? I also think that having the arch (read i386
not rtems) in the name is not needed. RPM takes care of the arch.
1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
vs
2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
example 1 makes a lot of sense to me and is how I would expect to find
the package naming convention.
Also, is Fedora ever going to ship a cross compiler for SuSE? I doubt
it. A cross compiler for cygwin? I doubt it.
I presume they are abbreviating and using <arch> as a synonym
for
"<arch>-suse-linux".
... Debian ..., their packaging is the worst of all possible choices.
It's neither browsable, nor complete nor correct, nor current.
Basically looks like rotten packages to me.
I wont get into debian packaging, as I have the joy of looking after
several user space packages and a kernel package for work, but its not
all bad
> Personally I like the cross-prefix, its a lot more obvious to an
end
> user what the package is and is for, but thats just me.
>
Everybody being used to cross tool chains, knows that the tools insided
are called <target>-<tools>.
Aye.. I use an arm tool chain for the xscale on a daily basis and you
are right, it is that is the naming convention of the tools. However, I
strongly disagree that this should be the naming convention for the
packages. As in my example, number 1 is much cleaner and obvious.
Regards
Michael
3:04 a.m.
On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote:
Ralf Corsepius wrote:
>> Why is the binary target name being used for the package name? That's
>> not intuitive to an end user at all IMHO.
>>
>> I think confusing the binary target name with the actual package name is
>> a mistake.
>>
>> gcc is gcc, not i386-redhat-linux-gcc
>>
> Wrong. What you have installed is an i386-redhat-linux-gcc rsp. a
> x86-68-redhat-linux-gcc (more precisely, a GCC having been configured
> for host=<arch>-redhat-linux). As this gcc also is the native gcc, it
> also is being installed as "gcc", which justifies the package to be
> called gcc.
>
Ok fair enough.
>> OpenSUSE uses cross-<arch>-gcc/binutils/whatever-version
>> debian looks like it uses gcc/binutils/whatever-<arch>-version
>>
>
> What is the <whatever>? That's the essential part of it.
>
Its not <whatever> it was /whatever/ implying insert cross tool here.
> A "cross-i386-gcc" would be complete non-sense, because a cross tool
> chain depends on the OS and several components more. An
> i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or
> a i386-redhat-gcc or a i386-suse-gcc.
>
Again, this is a packaging name, not a binary target. Packaged as
cross-arm-gcc for example, tells me straigh way what this package is.
Nope.
"arm-gcc" is complete non-sense, whether as a package name or as a
target name.
Again, the even the fact it is a cross compiler doesn't matter. It's a
package.
If one thinks your thought to an end, one ends up with any native into
native-<package>
However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy
binutils? A binutils addon?
With all due respect, now I can't resort to have
doubts on your
qualification.
I also think that having the arch (read i386
not rtems) in the name is not needed.
You have not understood.
The package contain a cross-tool chain, i.e. native i386-redhat-linux
applications having been configured to support binaries on other OSs
(here: rtems)
RPM takes care of the arch.
Nope, rpm only takes care about
the build arch. It doesn't take care
about target or host architectures
You are mixing up host and target.
1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
vs
2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
example 1 makes a lot of sense to me
Again, you are missing the point.
cross-rtems4.7 is insufficient and is nonsense.
There are many rtems cross toolschains, each of them addressing
different <arch>-rtems permutations (e.g. sparc-rtems4.7, or
mips-rtems4.7). They all contain native linux applications, but generate
code/objs for different OSes/architectures.
Also, is Fedora ever going to ship a cross compiler for SuSE? I doubt
it. A cross compiler for cygwin?
Do you want me to submit them? I have Fedora->FreeBSD6|Solaris5.7|MinGW|
Cygwin and ca. 8 rtems targets pending?
Due to license restrictions, Solaris won't ever go to the public, but I
may very well submit the others
I also could Canadian crossbuild Cygwin/MinGW rpms, of these toolchains,
but ... I am not interesting in promoting these OSes.
>> Personally I like the cross-prefix, its a lot more obvious
to an end
>> user what the package is and is for, but thats just me.
>>
>
> Everybody being used to cross tool chains, knows that the tools insided
> are called <target>-<tools>.
>
>
Aye.. I use an arm tool chain for the xscale on a daily basis
cf. below
and you
are right, it is that is the naming convention of the tools.
!!!!!!!!
Ralf
--
RTEMS Steering Committee Member mailto:ralf.corsepius@rtems.org
GCC Maintainer mailto:corsepiu@gcc.gnu.org
4:10 a.m.
On Fri, 2006-06-16 at 20:11 +1200, Michael J Knox wrote:
Ralf Corsepius wrote:
> With all due respect, now I can't resort to have doubts on your
> qualification.
>
Well, if I am not "qualified" to express my doubt or my opinion on such
a topic, I will leave to those that might be.
Well, in case you're still interested, you might want to check one of my
toolchains for <non-i386>-rtems4.7 targets:
ftp://packman.iu-bremen.de/fedora/4/SRPMS/
[Sorry, due to lack of bandwith, nosrc.rpms only and due to lack of time
and bandwidth no fc5 rpms, yet - I have them locally ... ]
May-be you'll then understand why these are not <sparc|mips|*>.rpms.
Ralf
11:42 a.m.
On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote:
Ralf Corsepius wrote:
> A "cross-i386-gcc" would be complete non-sense, because a cross tool
> chain depends on the OS and several components more. An
> i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or
> a i386-redhat-gcc or a i386-suse-gcc.
>
Again, this is a packaging name, not a binary target. Packaged as
cross-arm-gcc for example, tells me straigh way what this package is.
However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy
binutils? A binutils addon? I also think that having the arch (read i386
not rtems) in the name is not needed. RPM takes care of the arch.
1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
vs
2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
#1 Leaves out important information and will lead to naming conflicts.
Is this cross compiler going to generate code for rtems on a i386? A
ppc? A sparc? We don't know. Whatever naming convention is chosen
must include (i386, rtems4.7, binutils) as part of %{name} otherwise the
name is incomplete and will clash with other packages.
#2 Leaves the enduser browsing the package lists in the dark. As Jason
Tibbits wrote:
What is "i386" and why does it have a subpackage of
"rtems4.7"?
This is partially because '-' is used as a separator in rpm packages
(%{name}-%{version}-%{release}) and partially because we are conditioned
to expect "i386" at the end of the rpm.
I can see three choices:
1) Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
2) Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
3) Play games with the '-' to avoid the "it's an rpm separator"
association:
i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
FWIW, I think #2 has the most precedent.
-Toshio
3:48 p.m.
Toshio Kuratomi wrote:
On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote:
> Ralf Corsepius wrote:
>> A "cross-i386-gcc" would be complete non-sense, because a cross tool
>> chain depends on the OS and several components more. An
>> i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or
>> a i386-redhat-gcc or a i386-suse-gcc.
>>
> Again, this is a packaging name, not a binary target. Packaged as
> cross-arm-gcc for example, tells me straigh way what this package is.
> However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy
> binutils? A binutils addon? I also think that having the arch (read i386
> not rtems) in the name is not needed. RPM takes care of the arch.
>
> 1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
> vs
> 2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
#1 Leaves out important information and will lead to naming conflicts.
Is this cross compiler going to generate code for rtems on a i386? A
ppc? A sparc? We don't know. Whatever naming convention is chosen
must include (i386, rtems4.7, binutils) as part of %{name} otherwise the
name is incomplete and will clash with other packages.
Ah of course, yes :)
#2 Leaves the enduser browsing the package lists in the dark. As
Jason
Tibbits wrote:
> What is "i386" and why does it have a subpackage of "rtems4.7"?
This is partially because '-' is used as a separator in rpm packages
(%{name}-%{version}-%{release}) and partially because we are conditioned
to expect "i386" at the end of the rpm.
I can see three choices:
1) Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
2) Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
3) Play games with the '-' to avoid the "it's an rpm separator"
association:
i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
FWIW, I think #2 has the most precedent.
+1 on #2
Michael
8:14 p.m.
On Sat, 2006-06-17 at 08:48 +1200, Michael J. Knox wrote:
Toshio Kuratomi wrote:
> On Fri, 2006-06-16 at 19:39 +1200, Michael J Knox wrote:
>> Ralf Corsepius wrote:
>>> A "cross-i386-gcc" would be complete non-sense, because a cross
tool
>>> chain depends on the OS and several components more. An
>>> i386-rtems4.7-gcc is something very different from a i386-cygwin-gcc or
>>> a i386-redhat-gcc or a i386-suse-gcc.
>>>
>> Again, this is a packaging name, not a binary target. Packaged as
>> cross-arm-gcc for example, tells me straigh way what this package is.
>> However, i386-rtems4.7-binutils doesn't help tell what it is. A fancy
>> binutils? A binutils addon? I also think that having the arch (read i386
>> not rtems) in the name is not needed. RPM takes care of the arch.
>>
>> 1) cross-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>> vs
>> 2) i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>
> #1 Leaves out important information and will lead to naming conflicts.
> Is this cross compiler going to generate code for rtems on a i386? A
> ppc? A sparc? We don't know. Whatever naming convention is chosen
> must include (i386, rtems4.7, binutils) as part of %{name} otherwise the
> name is incomplete and will clash with other packages.
Ah of course, yes :)
> #2 Leaves the enduser browsing the package lists in the dark. As Jason
> Tibbits wrote:
>> What is "i386" and why does it have a subpackage of
"rtems4.7"?
>
> This is partially because '-' is used as a separator in rpm packages
> (%{name}-%{version}-%{release}) and partially because we are conditioned
> to expect "i386" at the end of the rpm.
>
> I can see three choices:
>
> 1) Ignore the enduser confusion and go with Ralf's naming:
> i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>
> 2) Namespace the whole thing:
> cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>
> 3) Play games with the '-' to avoid the "it's an rpm
separator"
> association:
> i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>
> FWIW, I think #2 has the most precedent.
+1 on #2
-10 on #2
Redundant info, over engineering, featuritis.
Users don't need to know it's a cross compiler/cross-toolchain nor do I
see any need why this should be necessary.
-maxint on #3
confusing.
Ralf
10:20 p.m.
On Sat, 17 Jun 2006 03:14:28 +0200, Ralf Corsepius wrote:
On Sat, 2006-06-17 at 08:48 +1200, Michael J. Knox wrote:
> Toshio Kuratomi wrote:
> > I can see three choices:
> >
> > 1) Ignore the enduser confusion and go with Ralf's naming:
> > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
> >
> > 2) Namespace the whole thing:
> > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
> >
> > 3) Play games with the '-' to avoid the "it's an rpm
separator"
> > association:
> > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
> >
> > FWIW, I think #2 has the most precedent.
>
> +1 on #2
-10 on #2
Redundant info, over engineering, featuritis.
Users don't need to know it's a cross compiler/cross-toolchain nor do I
see any need why this should be necessary.
-maxint on #3
confusing.
Ralf
FWIW, +1 on #2 speaking as an end-user aesthetic (i like the namespace
cross-* gives me).
Or what about a virtual provides of "crosscompiler" as a compromise?
zing
10:31 p.m.
On Fri, 2006-06-16 at 23:20 -0400, Zing wrote:
On Sat, 17 Jun 2006 03:14:28 +0200, Ralf Corsepius wrote:
> On Sat, 2006-06-17 at 08:48 +1200, Michael J. Knox wrote:
>> Toshio Kuratomi wrote:
>> > I can see three choices:
>> >
>> > 1) Ignore the enduser confusion and go with Ralf's naming:
>> > i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>> >
>> > 2) Namespace the whole thing:
>> > cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>> >
>> > 3) Play games with the '-' to avoid the "it's an rpm
separator"
>> > association:
>> > i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>> >
>> > FWIW, I think #2 has the most precedent.
>>
>> +1 on #2
>
> -10 on #2
> Redundant info, over engineering, featuritis.
> Users don't need to know it's a cross compiler/cross-toolchain nor do I
> see any need why this should be necessary.
>
> -maxint on #3
> confusing.
>
> Ralf
FWIW, +1 on #2 speaking as an end-user aesthetic (i like the namespace
cross-* gives me).
What does cross-* give you?
Do you care about the fact it's a cross compiler?
No, you don't. You don't want a "cross-compiler", you actually want a
compiler targeting a certain target: You want a mips-elf-gcc or an
arm-rtems4.7-gcc or a sparc-sun-solaris2.8-gcc.
Or what about a virtual provides of "crosscompiler" as a
compromise?
Completely meaningless. There is are many cross compilers. Each of
them
is targeting one of many targets, so a "Provides: crosscompiler" would
cause conflicts.
Ralf
1:01 a.m.
So how does this progress?
We have had three suggested naming conventions, thanks to Toshio
Kuratomi, with most of the weight leaning on #2, to recap them:
1) Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
2) Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
3) Play games with the '-' to avoid the "it's an rpm separator"
association:
i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
So far, there has been no resolve. Do we need to have more people have a
say? Is this a storm in a tea cup?
Thanks
Michael
1:17 a.m.
>>>> "MJK" == Michael J Knox
<michael(a)knox.net.nz> writes:
MJK> So how does this progress?
At this point the operation and possibly even the composition of the
packaging committee has not been finalized. So we'll need spot to
weigh in; either he makes the decision as the sole component of the
current committee or we finalize a committee make up, meeting
schedule, quorum rule, voting process and such.
- J<
2:29 a.m.
On Sat, 2006-06-17 at 18:01 +1200, Michael J. Knox wrote:
Is this a storm in a tea cup?
Yes, mostly.
I've proposed a set of packages, which has not made any progress wrt. a
review for almost 1/2 a year.
Now, people start nitpicking/nagging on details, some of them don't
understand.
The next nitpicking I expect to happen is GCC using
$prefix/$target_alias/, which tangles a defect/leak of the FHS.
Then they will start nit-picking on the magic these spec files contain
to work-around rpm's bugs wrt. handling foreign binaries.
You probably will be able to relate why I feel really pissed about this.
Ralf
10:20 a.m.
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> I've proposed a set of packages, which has not made any progress
RC> wrt. a review for almost 1/2 a year.
I saw those old packages and thought some progress needed to be made.
I'm sorry they sat for so long, I really am. But I saw an issue with
the naming and came here to ask, as is the proper procedure.
RC> Now, people start nitpicking/nagging on details, some of them
RC> don't understand.
And look at what I get. Yep, I don't understand enough to question
Ralf's naming decisions. Or apparently any of his other decisions:
RC> The next nitpicking I expect to happen is GCC using
RC> $prefix/$target_alias/, which tangles a defect/leak of the FHS.
Well, yes, if I were to be foolish enough to continue to attempt to
review your packages, I would come back here with more questions if I
had them. Which is what I understand that I'm supposed to do.
So, Ralf, if you don't think anyone should question your packaging
decisions, I really don't know what to tell you. Perhaps, "tough" is
appropriate. If I see anything that's out of line with the current
guidelines, anything that sets new precedent, any fancy specfile trick
or rpm bug workaround that isn't commented, or even anything I don't
understand (which I'll tell you now is quite a bit) then I'm going to
question it.
And that's a good thing. Why? Because that's how the process is
supposed to work. Short of some committee somewhere passing a "Ralf's
packages go right on through" rule, all of your packages are going to
have to go through the review process.
RC> You probably will be able to relate why I feel really pissed about
RC> this.
As far as I can see, the only thing you might have cause for being
angry about is the fact that your packages sat there for six months.
Which really is too bad, but this is a volunteer effort. And I will
admit to looking at them several times in the past without acting on
them, because being familiar with the tone of the messages I've seen
from you in the past I knew I was going to be in for a rough time.
But this time I thought to myself, "Hey, there's a packaging committee
now. Both Ralf and I have been invited to join it, and spot must have
confidence in our abilities to work together. So surely we can have a
reasonable discussion about any issues I find."
So here we are, and in all honesty I must say I'm a bit disappointed
at the way things are working out. But I'm not in the least angry,
and I an perfectly happy to keep working on your packages, and indeed
to nitpick them to death if that's what it takes to get them into
shape for Extras.
- J<
3:31 p.m.
On Sat, 2006-06-17 at 10:20 -0500, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> The next nitpicking I expect to happen is GCC using
RC> $prefix/$target_alias/, which tangles a defect/leak of the FHS.
Well, yes, if I were to be foolish enough to continue to attempt to
review your packages, I would come back here with more questions if I
had them. Which is what I understand that I'm supposed to do.
So, Ralf, if you don't think anyone should question your packaging
decisions,
Questioning decison is one side of the medal, cluelessness is another
one.
The choice of package names is my decision, true, and is how we (rtems)
ship them for many years.
But the rest is not my decisions. It's how GCC cross-compilers work,
ever since they exist. Cross-compilers are a bit more complex than
native tools and impose demands the FHS and the FE guidelines don't
cover.
I really don't know what to tell you. Perhaps,
"tough" is
appropriate.
"Though" is what I had expected and what I am willing to
cope with,
but ... cluelessness is hard to bare.
If I see anything that's out of line with the current
guidelines, anything that sets new precedent, any fancy specfile trick
or rpm bug workaround that isn't commented, or even anything I don't
understand (which I'll tell you now is quite a bit) then I'm going to
question it.
And that's a good thing. Why? Because that's how the process is
supposed to work. Short of some committee somewhere passing a "Ralf's
packages go right on through" rule,
Absolutely not.
all of your packages are going to
have to go through the review process.
I am asking reviewers to *THINK*.
Unfortunately, I feel some people prefer to take the Guidelines as God
sent laws they try to stick to word by word. The Guidelines, the FHS and
the LSB have been written by humans with limited horizons/knowledge, are
full of inconsistencies and defects, which ought to be found and closed.
RC> You probably will be able to relate why I feel really pissed
about
RC> this.
As far as I can see, the only thing you might have cause for being
angry about is the fact that your packages sat there for six months.
The fact you
are missing: These package's history.
So here we are, and in all honesty I must say I'm a bit
disappointed
at the way things are working out.
Well, ... contribution to Fedora is
disappointing and takes a very long
breath ...
Ralf
11:19 a.m.
kindling the issue, but I'm building an arm buildchain myself right now.
On Fri, 16 Jun 2006, Toshio Kuratomi wrote:
I can see three choices:
1) Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
2) Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
3) Play games with the '-' to avoid the "it's an rpm separator"
association:
i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
FWIW, I think #2 has the most precedent.
What about reshuffling the components a bit?
binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm?
regards,
andreas
11:53 a.m.
On Wed, 2006-06-28 at 18:19 +0200, Andreas Thienemann wrote:
kindling the issue, but I'm building an arm buildchain myself
right now.
On Fri, 16 Jun 2006, Toshio Kuratomi wrote:
> I can see three choices:
>
> 1) Ignore the enduser confusion and go with Ralf's naming:
> i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>
> 2) Namespace the whole thing:
> cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>
> 3) Play games with the '-' to avoid the "it's an rpm
separator"
> association:
> i386_rtems4.7_binutils-2.16.1-0.20051229.1.fc6.i386.rpm
>
> FWIW, I think #2 has the most precedent.
What about reshuffling the components a bit?
binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm?
Confusing, because
a) in repos, other packages from this toolchain will not be next to each
other, i.e. hardly browsable.
b) How would you want to call other add on package for your toolchain?
libc-i386-arm? libncurses-i386-arm?
c) The fact your toolchain is running on i386's already is part of the
rpm's NVR-$arch.rpm => the i386 is redundant and superfluos.
d) "arm" is an architecture and is not sufficient to describe a
toolchain's target. A toolchain's target consists of more.
In case of "bare metal toolchain" (No OS, no libc), this could be
arm-elf or arm-bare-elf or even arm-coff.
Ralf
8:26 p.m.
On Wed, 28 Jun 2006, Ralf Corsepius wrote:
> binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm?
Confusing, because
a) in repos, other packages from this toolchain will not be next to each
other, i.e. hardly browsable.
Correct.
But the binutils will be together with the host binutils and other cross
compiler binutils.
That can be considered nice as well.
b) How would you want to call other add on package for your
toolchain?
libc-i386-arm? libncurses-i386-arm?
glibc-i386-arm-elf probably.
But one could also go with prepending cross- to make the distinction
clearer.
c) The fact your toolchain is running on i386's already is part
of the
rpm's NVR-$arch.rpm => the i386 is redundant and superfluos.
I thought about
leaving it out, but considered it clearer to just name it
without having to force the user to shift his eyes to the right and look
for the arch tag.
d) "arm" is an architecture and is not sufficient to
describe a
toolchain's target. A toolchain's target consists of more.
In case of "bare metal toolchain" (No OS, no libc), this could be
arm-elf or arm-bare-elf or even arm-coff.
You're right about that. I meant
arm-elf, as this is what I was building,
but simply forgot about the -elf part.
regards,
andreas
1:26 a.m.
andreas(a)bawue.net (Andreas Thienemann) writes:
What about reshuffling the components a bit?
binutils-i386-arm-%{version}-%{release}.%{dist}.%{target}.rpm?
With this naming, you will run into problems when you use subpackages
and you have to use '-n' everytime. E.g.
| Name: glibc-%crossarch
| ...
| %package devel
will result into 'glibc-%crossarch-devel' else.
Enrico
6:57 a.m.
On Thu, 2006-06-29 at 08:26 +0200, Enrico Scholz wrote:
With this naming, you will run into problems when you use
subpackages
and you have to use '-n' everytime.
Not throwing in an opinion towards any of the suggestions, but what's
the actual problem with using -n to set subpackage names whenever
necessary?
7:10 a.m.
ville.skytta(a)iki.fi (Ville Skyttä) writes:
> [... <crossarch>-<name> or
<name>-<crossarch> ...]
> With this naming, you will run into problems when you use subpackages
> and you have to use '-n' everytime.
Not throwing in an opinion towards any of the suggestions, but what's
the actual problem with using -n to set subpackage names whenever
necessary?
It will be necessary *evertime*. And the '-n' will not influence the
'%package' statement only but common expressions like
| Requires: %name-lib = %version-%release
Enrico
7:32 a.m.
On Thu, 2006-06-29 at 14:10 +0200, Enrico Scholz wrote:
ville.skytta(a)iki.fi (Ville Skyttä) writes:
> Not throwing in an opinion towards any of the suggestions, but
what's
> the actual problem with using -n to set subpackage names whenever
> necessary?
It will be necessary *evertime*. And the '-n' will not influence the
'%package' statement only but common expressions like [...]
Sure, but where's the *problem*?
10:06 a.m.
ville.skytta(a)iki.fi (Ville Skyttä) writes:
> > Not throwing in an opinion towards any of the suggestions,
but
> > what's the actual problem with using -n to set subpackage names
> > whenever necessary?
>
> It will be necessary *evertime*. And the '-n' will not influence the
> '%package' statement only but common expressions like [...]
Sure, but where's the *problem*?
You have to use the full packagename everytime which clutters up the
spec file.
Enrico
11:01 a.m.
On Thu, 2006-06-29 at 17:06 +0200, Enrico Scholz wrote:
ville.skytta(a)iki.fi (Ville Skyttä) writes:
>> It will be necessary *evertime*. And the '-n' will not influence the
>> '%package' statement only but common expressions like [...]
>
> Sure, but where's the *problem*?
You have to use the full packagename everytime which clutters up the
spec file.
Doesn't qualify as a real problem IMO.
and: -debuginfo packages will be named incorrectly.
That's derived from the "main" (source) package name no matter if -n is
used inside the specfile or not. Again, I see no problem there, and do
think that "incorrectly" is an overstatement.
Anyway, I'll stop handwaving about implementation details now, and let
others concentrate on the original issues.
10:08 a.m.
ville.skytta(a)iki.fi (Ville Skyttä) writes:
> > Not throwing in an opinion towards any of the suggestions,
but
> > what's the actual problem with using -n to set subpackage names
> > whenever necessary?
>
> It will be necessary *evertime*. And the '-n' will not influence the
> '%package' statement only but common expressions like [...]
Sure, but where's the *problem*?
and: -debuginfo packages will be named incorrectly.
Enrico
6504
days inactive
6517
days old
packaging@lists.fedoraproject.org
29 comments
8 participants
participants (8)
-
Andreas Thienemann -
Enrico Scholz -
Jason L Tibbitts III -
Michael J. Knox -
Ralf Corsepius -
Toshio Kuratomi -
Ville Skyttä -
Zing