https://bugzilla.redhat.com/show_bug.cgi?id=1350884
Jonathan Wakely <jwak...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jwak...@redhat.com
--- Comment #35 from Jonathan Wakely <jwak...@redhat.com> ---
(In reply to Brandon Nielsen from comment #32)
> Spec URL:
> https://copr-be.cloud.fedoraproject.org/results/nielsenb/msp430-development-
> tools/fedora-rawhide-x86_64/01577708-msp430-elf-toolchain/msp430-elf-
> toolchain.spec
When creating the symlinks for the binutils executables I'd be tempted to do:
# Symlink binutils so we can build GCC
mkdir bin
for i in addr2line ar cxxfilt elfedit gprof libtool objcopy objdump ranlib
readelf size strings
do
ln -sr binutils/binutils/$i bin/%{target}-$i
done
for i in as ld nm strip
do
ln -sr binutils/binutils/$i-new bin/%{target}-$i
done
Personally I find it a bit easier to read because it's less of a wall of text,
and it's clear which ones are linked using the same name and which ones aren't.
But that's just me, what you have is fine.
I don't think building GCC actually needs most of these, but it doesn't hurt to
add them.
> > I would check whether it's possible to replace the "*-devel" lines with
> > "pkgconfig(foo)" like you did in the other cases.
> >
>
> I don't see a pkgconfig provided by gmp-devel or libmpc-devel.
Right.
> I got rid of the remaining libtool archive. I'm afraid I don't understand
> what header files or static objects shouldn't be there. This is a compiler,
> those are required for it to function.
>
> > Package Review
> > ==============
> >
> > Legend:
> > [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
> > [ ] = Manual review needed
> >
> >
> > Issues:
> > =======
> > - Header files in -devel subpackage, if present.
> > **Lots of leftover header files in subdirs of /usr/msp430-elf**
> > See: https://docs.fedoraproject.org/en-US/packaging-
> > guidelines/#_devel_packages
>
> It's a compiler, the headers are necessary as far as I'm aware.
It's possible the msp430-elf-gcc package won't actually work without some of
those headers, so there's no benefit to putting them in a separate -devel
package.
But it's not true for all of them.
The files in /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/plugin/ are not strictly
necessary to use the compiler, only if you want to build GCC plugins for
msp430-elf. You could either not bother packaging the plugin support at all, or
you could leave it in the main msp430-elf-gcc package (which is what the
avr-gcc package appears to do too).
The files in /usr/msp430-elf/msp430-elf/include/ appear to be the newlib libc
headers. In theory they could be put in a separate msp430-elf-newlib-devel
subpackage. Code which doesn't use anything from the C standard library could
still be compiled by msp430-elf-gcc without the newlib headers.
> > - Static libraries in -static or -devel subpackage, providing -devel if
> > present.
> > Note: Package has .a files: msp430-elf-gcc, msp430-elf-gcc-c++. Illegal
> > package name: msp430-elf-gcc, msp430-elf-gcc-c++. Does not provide
> > -static: msp430-elf-gcc, msp430-elf-gcc-c++.
> > See: https://docs.fedoraproject.org/en-US/packaging-
> > guidelines/#packaging-static-libraries
>
> Again, this is a compiler, as far as I know, those are necessary.
Again, true for some of those libs that msp430-elf-gcc depends on, but not true
for the ones in msp430-elf-gcc-c++.
Fedora's native GCC package puts the C++ standard library headers and libs into
separate packages, not part of gcc-c++. Specifically, libstdc++-devel and
libstdc++-static.
That means the gcc-c++ package can be used to compile C++ code that doesn't
depend on the standard library or the C++ runtime. But for most practical uses
you also need to install libstdc++-devel (and for static linking,
libstdc++-static as well).
That said, this seems like a reasonable way to split the packages up. There's
probably not much practical benefit to more granularity for the stdlib files.
> >
> >
> > ===== MUST items =====
> >
> > C/C++:
> > [x]: Package does not contain kernel modules.
> > [?]: Package contains no static executables.
> > [!]: Development (unversioned) .so files in -devel subpackage, if present.
> > Note: Unversioned so-files in private %_libdir subdirectory (see
> > attachment). Verify they are not in ld path.
>
> I agree this is gross, but it's not in "regular" gcc's ld path, so I think
> it's okay?
Yes, I think these are OK where they are:
msp430-elf-gcc: /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/plugin/libcc1plugin.so
msp430-elf-gcc: /usr/msp430-elf/lib/gcc/msp430-elf/9.2.0/plugin/libcp1plugin.so
msp430-elf-gcc: /usr/msp430-elf/libexec/gcc/msp430-elf/9.2.0/liblto_plugin.so
They're specific to this build of GCC, and won't be used by anything else.
> > [!]: Changelog in prescribed format.
> > Macros in changelog are not allowed.
>
> I'm not actually using the macro, it's just a comment. Should I escape it
> somehow? Or just modify the comment.
As mentioned in comment 33, either remove it or escape it with %%.
> > [!]: Fully versioned dependency in subpackages if applicable.
> > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
> > msp430-elf-gcc , msp430-elf-gcc-c++ , msp430-elf-gdb , msp430-elf-
> > binutils
> > Review: it's a good idea to include this.
>
> I'm not sure I understand. I've added some missing requires (the C++
> compiler now requires the C compiler, the C compiler now requires binutils),
> but if I add the "Requires: {name}%{?_isa} = %{version}-%{release}"
> requested, I just get packages that are uninstallable. Is there some
> documentation I can look at to see an example of what's being requested?
I think you want %{?_isa} to be present on the Requires tags, otherwise it's
possible for a user to manually install the 32-bit msp430-elf-binutils.i686
package on an x86_64 and have that satisfy the requirement for
msp430-elf-binutils. But what you're really trying to require is the
msp430-elf-binutils.x86_64 one, so you need the %{?_isa} suffix.
I agree that you don't want the subpackages to require the main one, but that's
because the main one doesn't actually exist ... no msp430-elf-toolchain package
actually gets created.
Shouldn't that main package be an umbrella package that installs the others,
i.e. the main package should have:
Requires: %{name}-binutils%{?_isa} = %{version}-%{release}
Requires: %{name}-gcc%{?_isa} = %{version}-%{release}
Requires: %{name}-gcc-c++%{?_isa} = %{version}-%{release}
Requires: %{name}-gdb%{?_isa} = %{version}-%{release}
That would allow you to say 'dnf install msp430-elf-toolchain' and get all of
the subpackages at once.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/package-review@lists.fedoraproject.org
