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<
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
"RC" == Ralf Corsepius rc040203@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<
On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote:
"RC" == Ralf Corsepius rc040203@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
Ralf Corsepius wrote:
On Thu, 2006-06-15 at 23:19 -0500, Jason L Tibbitts III wrote:
> "RC" == Ralf Corsepius rc040203@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
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@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
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
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.
- 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
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
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.
- 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
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.
- 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:
- Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- 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
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.
- 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:
- Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- 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
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:
- Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- 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
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:
- Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- 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
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
"MJK" == Michael J Knox michael@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<
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
"RC" == Ralf Corsepius rc040203@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<
On Sat, 2006-06-17 at 10:20 -0500, Jason L Tibbitts III wrote:
"RC" == Ralf Corsepius rc040203@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
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:
- Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- 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
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:
- Ignore the enduser confusion and go with Ralf's naming:
i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- Namespace the whole thing:
cross-i386-rtems4.7-binutils-2.16.1-0.20051229.1.fc6.i386.rpm
- 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
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
andreas@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
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?
ville.skytta@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
On Thu, 2006-06-29 at 14:10 +0200, Enrico Scholz wrote:
ville.skytta@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*?
ville.skytta@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
On Thu, 2006-06-29 at 17:06 +0200, Enrico Scholz wrote:
ville.skytta@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.
ville.skytta@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
packaging@lists.fedoraproject.org
-
Andreas Thienemann -
Enrico Scholz -
Jason L Tibbitts III -
Michael J. Knox -
Ralf Corsepius -
Toshio Kuratomi -
Ville Skyttä -
Zing