Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Jon Ciesla <limburgher(a)gmail.com> changed:
What |Removed |Added
--- Comment #8 from Jon Ciesla <limburgher(a)gmail.com> 2012-04-10 08:19:55 EDT ---
(In reply to comment #7)
Thanks for taking care of this. I took a look at the changes done here because
of new build failures on rawhide. A few comments:
> -BuildRequires: gettext
> +BuildRequires: gettext-devel
Why is it necessary to change this? It used to build fine with BR: gettext as
it only needs the tools from gettext package for building and doesn't use the
headers that are in -devel.
> -Requires: gettext-devel
> +Requires: gettext
Requiring gettext-devel was a deliberate change in
you ever need to find out why some line is the way it is, 'git blame' can help
for history digging.
Because typically, bits that are needed to build other tools against a given
package live in -devel, and bits needed at runtime are in the base package.
-devel requires base. I understand that this may not always be the case,
especially with tools used in development, such as intltool, but that this
breaks builds suggests that gettext's file layout might bear re-examination.
Looking at that commit simply tells me that the BR was changed, not why. No BZ
or problem is mentioned.
Packages that used to rely on intltool dragging in gettext-devel are
failing to build, e.g. gtranslator:
If you think it's important to depend on gettext instead of gettext-devel, can
you send out a heads up to fedora-devel list that packages will now have to
explicitly BR gettext-devel, instead of relying on intltool dragging it in? I
fear the ARM secondary arch people aren't very happy about new FTBFS failures,
so it's best to try to get package maintainers to fix these early.
Agreed. I'm adding the gettext maintainer for his thoughts on the best
resolution to this.
> -Obsoletes: xml-i18n-tools
> -Provides: xml-i18n-tools = 0.11
> +#Obsoletes: xml-i18n-tools
> +#Provides: xml-i18n-tools = 0.11
Perhaps remove these lines completely, to avoid cluttering the spec file with
commented out lines? Any changes are permanently recorded in git history, so
it's always possible to revert them at a later date.
I do that on my specs, but typically leave them in place for faster reverting
on those belonging to others.
Thanks again for taking care of the merge review.
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.