Hi,
I recently upgrade my host from f26 to f28. But to keep compatible with old behavior, I am figuring out a way to revert the change 'Separate Subpackage and Source Debuginfo'[1]. That means let rpm not generate debugsource and subpackage debuginfo. Simply adding '%_debugsource_packages 0' to ~/.rpmmacros does not work.
[1] http://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
-robin
On Thu, 3 May 2018 11:08:47 +0800 Robin Lee cheeselee@fedoraproject.org wrote:
Hi,
I recently upgrade my host from f26 to f28. But to keep compatible with old behavior, I am figuring out a way to revert the change 'Separate Subpackage and Source Debuginfo'[1]. That means let rpm not generate debugsource and subpackage debuginfo. Simply adding '%_debugsource_packages 0' to ~/.rpmmacros does not work.
[1] http://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
A possible suggestion:
From /usr/lib/rpm/redhat/macros """ #============================================================================== # ---- configure macros. note that most of these are inherited # from the defaults. # %_localstatedir /var
%_pkgdocdir %{_docdir}/%{name} %_docdir_fmt %%{NAME}
%_fmoddir %{_libdir}/gfortran/modules
%_enable_debug_packages 1 %_include_minidebuginfo 1 %_include_gdb_index 1 %_debugsource_packages 1 %_debuginfo_subpackages 1 """
From the man page for rpmbuild: """ --with OPTION Enable configure OPTION for build.
--without OPTION Disable configure OPTION for build. """
Does adding the option --without _enable_debug_packages to the end of the rpmbuild line work? If it does, you could just disable any other debug options above that you don't want the same way.
You could ask on the fedora-devel list where people will be more familiar with this topic.
stan wrote:
From the man page for rpmbuild: """ --with OPTION Enable configure OPTION for build.
--without OPTION Disable configure OPTION for build. """
Does adding the option --without _enable_debug_packages to the end of the rpmbuild line work? If it does, you could just disable any other debug options above that you don't want the same way.
The --with/--without arguments toggle conditions set via %bcond_with and %bcond_without. So that won't do what Robin wants.
More details on --with/--without are here:
http://rpm.org/user_doc/conditional_builds.html
On Wed, 2 May 2018 23:57:53 -0400 Todd Zullinger tmz@pobox.com wrote:
stan wrote:
From the man page for rpmbuild: """ --with OPTION Enable configure OPTION for build.
--without OPTION Disable configure OPTION for build. """
Does adding the option --without _enable_debug_packages to the end of the rpmbuild line work? If it does, you could just disable any other debug options above that you don't want the same way.
The --with/--without arguments toggle conditions set via %bcond_with and %bcond_without. So that won't do what Robin wants.
More details on --with/--without are here:
Thanks.
My knowledge of this is minimal, but I was going by the kernel, which was probably a bad choice, as the kernel is unique. There, passing --without-debuginfo turns off debug package generation, but that is probably due to special coding in the spec file, shown below. """ # The following build options are enabled by default. # Use either --without <opt> in your rpmbuild command or force values # to 0 in here to disable them. # # standard kernel %define with_up %{?_without_up: 0} %{?!_without_up: 1} # kernel PAE (only valid for i686 (PAE) and ARM (lpae)) %define with_pae %{?_without_pae: 0} %{?!_without_pae: 0} # kernel-debug %define with_debug %{?_without_debug: 0} %{?!_without_debug: 0} # kernel-headers %define with_headers %{?_without_headers: 0} %{?!_without_headers: 1} %define with_cross_headers %{?_without_cross_headers: 0} %{?!_without_cross_headers: 0} # kernel-debuginfo %define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 0} # kernel-bootwrapper (for creating zImages from kernel + initrd) %define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper: 1} # Want to build a the vsdo directories installed %define with_vdso_install %{?_without_vdso_install: 0} %{?!_without_vdso_install: 1} # # Additional options for user-friendly one-off kernel building: # # Only build the base kernel (--with baseonly): %define with_baseonly %{?_with_baseonly: 1} %{?!_with_baseonly: 0} # Only build the pae kernel (--with paeonly): %define with_paeonly %{?_with_paeonly: 1} %{?!_with_paeonly: 0} # """
stan wrote:
On Wed, 2 May 2018 23:57:53 -0400 Todd Zullinger tmz@pobox.com wrote:
The --with/--without arguments toggle conditions set via %bcond_with and %bcond_without. So that won't do what Robin wants.
More details on --with/--without are here:
Thanks.
My knowledge of this is minimal, but I was going by the kernel, which was probably a bad choice, as the kernel is unique. There, passing --without-debuginfo turns off debug package generation, but that is probably due to special coding in the spec file, shown below.
[...]
Well... I didn't go into all the details about how the --with/--without options work. I started to write more in my initial reply, but then I thought I was getting too deep in the weeds, so I dropped that. ;)
For a little more detail on it, the kernel isn't doing anything special there with regards to --with/--without. They're doing essentially what the %bcond_with/out macros do.
In /usr/lib/rpm/macros, %bcond_with and %bcond_without are defined like this:
%bcond_with() %{expand:%%{?_with_%{1}:%%global with_%{1} 1}} %bcond_without() %{expand:%%{!?_without_%{1}:%%global with_%{1} 1}}
They're really just shortcuts for setting %with_$foo and related macros. You can read more in the macros file, starting around line 104 in rpm-4.14.0:
https://github.com/rpm-software-management/rpm/blob/rpm-4.14.0-release/macro...
It's a lot of macro work there, but it boils down to making things easier for packages to use the %bcond macros and the --with/--without command line arguments. Even the command line arguments are just shortcuts to define %_with_$foo and %_without_$foo macros.
Hopefully that's at least mildly interesting and/or useful information. More importantly, I hope I managed to sum it up reasonably, without any major errors. ;)
Robin Lee wrote:
I recently upgrade my host from f26 to f28. But to keep compatible with old behavior, I am figuring out a way to revert the change 'Separate Subpackage and Source Debuginfo'[1]. That means let rpm not generate debugsource and subpackage debuginfo. Simply adding '%_debugsource_packages 0' to ~/.rpmmacros does not work.
That should be the macro which controls the debugsource packages. What's your build setup look like? In other words, what tools are you using and what releases are you targeting?
I would suggest building with mock, as that should get you the proper defaults for each release target (among other benefits).
Perhaps if you provide more details on what your doing and how it fails someone here will be able to spot the issue and suggest a solution or work-around.
On Thu, May 3, 2018 at 12:03 PM, Todd Zullinger tmz@pobox.com wrote:
Robin Lee wrote:
I recently upgrade my host from f26 to f28. But to keep compatible with old behavior, I am figuring out a way to revert the change 'Separate Subpackage and Source Debuginfo'[1]. That means let rpm not generate debugsource and subpackage debuginfo. Simply adding '%_debugsource_packages 0' to ~/.rpmmacros does not work.
That should be the macro which controls the debugsource packages. What's your build setup look like? In other words, what tools are you using and what releases are you targeting?
I would suggest building with mock, as that should get you the proper defaults for each release target (among other benefits).
Perhaps if you provide more details on what your doing and how it fails someone here will be able to spot the issue and suggest a solution or work-around.
-- Todd
Intaxication (n.) Euphoria at getting a tax refund, which lasts until you realize it was your money to start with.
It doest not work with _debugsource_packages set to 0. $ rpm --define '_debugsource_packages 0' --eval '%{?_debugsource_packages:%_debugsource_template}'
%package debugsource Summary: Debug sources for package %{name} Group: Development/Debug AutoReqProv: 0 %description debugsource This package provides debug sources for package %{name}. Debug sources are useful when developing applications that use this package or when debugging this package. %files debugsource -f debugsourcefiles.list
Undefining it would actually get the latter macro silent: rpm --undefine '_debugsource_packages' --eval '%{?_debugsource_packages:%_debugsource_template}'
But even using the undefining method, debugsource subpakcage will still be generated. This is the most strange case:
$ rpm --undefine '_debugsource_packages' -q --specfile check.spec check-0.9.4-1.fc28.x86_64 check-devel-0.9.4-1.fc28.x86_64 check-debuginfo-0.9.4-1.fc28.x86_64 check-debugsource-0.9.4-1.fc28.x86_64
Redefining _debugsource_template will make debugsource disappear, but that's too tricky. $ rpm --define '_debugsource_template %{nil}' -q --specfile check.spec check-0.9.4-1.fc28.x86_64 check-devel-0.9.4-1.fc28.x86_64 check-debuginfo-0.9.4-1.fc28.x86_64
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Robin Lee wrote:
On Thu, May 3, 2018 at 12:03 PM, Todd Zullinger tmz@pobox.com wrote:
Robin Lee wrote:
I recently upgrade my host from f26 to f28. But to keep compatible with old behavior, I am figuring out a way to revert the change 'Separate Subpackage and Source Debuginfo'[1]. That means let rpm not generate debugsource and subpackage debuginfo. Simply adding '%_debugsource_packages 0' to ~/.rpmmacros does not work.
[...]
It doest not work with _debugsource_packages set to 0.
Indeed. I played around for a bit last night, to no avail.
It's not clear to me from the rpm documentation, source comments, or git history whether this is intentional or not. It may be a case that wasn't tested. Or it could be intended that it's turned on at the distro level and can only be disabled in individual packages. That would help improve reproducibility.
I think you'd have to ask the rpm maintainers about this to be sure.
I'm still not clear on why you want to do this. I know I don't need to know that. I'm curious mostly and knowing why this is a problem might help someone here see another way to solve it. :)
Is the goal to build binary, non-noaarch packages on f28 that you can use on older releases -- including the debuginfo? That seems unlikely to be ideal, but I'm guessing at your use-case.
If it's just curiosity, then I understand. Sorry I can't help with a better answer in that case. I can at least confirm that it doesn't appear to be a macro you can override short of changing the setting in the system-wide macros file or individual spec file. :)
On Fri, May 4, 2018 at 12:08 AM, Todd Zullinger tmz@pobox.com wrote:
Robin Lee wrote:
On Thu, May 3, 2018 at 12:03 PM, Todd Zullinger tmz@pobox.com wrote:
Robin Lee wrote:
I recently upgrade my host from f26 to f28. But to keep compatible with old behavior, I am figuring out a way to revert the change 'Separate Subpackage and Source Debuginfo'[1]. That means let rpm not generate debugsource and subpackage debuginfo. Simply adding '%_debugsource_packages 0' to ~/.rpmmacros does not work.
[...]
It doest not work with _debugsource_packages set to 0.
Indeed. I played around for a bit last night, to no avail.
It's not clear to me from the rpm documentation, source comments, or git history whether this is intentional or not. It may be a case that wasn't tested. Or it could be intended that it's turned on at the distro level and can only be disabled in individual packages. That would help improve reproducibility.
I think you'd have to ask the rpm maintainers about this to be sure.
I'm still not clear on why you want to do this. I know I don't need to know that. I'm curious mostly and knowing why this is a problem might help someone here see another way to solve it. :)
I am using the planex[1] tool to do massive rpm rebuild. It use something like 'rpm -q --specfile' to predict the result rpms, and generate a dependency tree. And then use this info to build rpms in el7 mock one by one.
I then use the ''%_debugsource_template %{nil}' trick, which can satisfy planex by now.
[1] https://github.com/xenserver/planex
Is the goal to build binary, non-noaarch packages on f28 that you can use on older releases -- including the debuginfo? That seems unlikely to be ideal, but I'm guessing at your use-case.
If it's just curiosity, then I understand. Sorry I can't help with a better answer in that case. I can at least confirm that it doesn't appear to be a macro you can override short of changing the setting in the system-wide macros file or individual spec file. :)
-- Todd
If age imparted wisdom, there wouldn't be any old fools. -- Claudia Young _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Robin Lee wrote:
I am using the planex[1] tool to do massive rpm rebuild. It use something like 'rpm -q --specfile' to predict the result rpms, and generate a dependency tree. And then use this info to build rpms in el7 mock one by one.
I then use the ''%_debugsource_template %{nil}' trick, which can satisfy planex by now.
Cool, that looks handy. Is planex intended to support generating srpms on newer systems like Fedora and building on RHEL/CentOS? That seems like a recipe for other odd failures, particularly as rpm development has picked up a bit recently. We're likely to see more changes with each Fedora release (or at least far more often than they end up in RHEL/CentOS). :)
The mock --buildsrpm might be better for this than using rpmbuild directly on the host. Coupled with mock's --resultdir argument it doesn't look like it would be all tht hard to replace rpmbuild in planex/cmd/makesrpm.py with a mock equivalent. Maybe that would even be done optionally, if the target OS differs from the host OS. That would help planex guard against the next incompatible change.
It is still odd that there's no way to override the _debugsource_packages macro once it's set. I'd say it's worth asking the rpm folks if that's intentional or not. It may be a bug that they'll fix.
-
Robin Lee -
stan -
Todd Zullinger