https://bugzilla.redhat.com/show_bug.cgi?id=1350884 Jonathan Wakely <jwakely@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwakely@xxxxxxxxxx --- Comment #35 from Jonathan Wakely <jwakely@xxxxxxxxxx> --- (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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
