[Bug 426922] Review Request: gpar2 - GUI for verifying and repairing PAR and PAR2 recovery sets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: gpar2 - GUI for verifying and repairing PAR and PAR2 recovery sets


https://bugzilla.redhat.com/show_bug.cgi?id=426922





------- Additional Comments From wolfy@xxxxxxxxxxxxxxxxxx  2007-12-29 16:18 EST -------
The food news is that all problems mentioned above are fixed.
The bad news is that I think that a program should fail if the proper BR are not
met. Since in this specific situation the build does not fail in the absence of
gettext, I have been investigating a bit more and I think that we have a problem. 


I did a diff between the build logs with and without gettext as BR and the only
differences I did spot in the build log are
< checking for msgfmt... /usr/bin/msgfmt
< checking for gmsgfmt... /usr/bin/msgfmt
< checking for xgettext... /usr/bin/xgettext
< checking for msgmerge... /usr/bin/msgmerge
---
> checking for msgfmt... no
> checking for gmsgfmt... :
> checking for xgettext... no
> checking for msgmerge... no

After that I decided to look at the source and voila: it looks to me that gpar2
ships both it's own private copy of gettext and also a fr.gmo file which is
simply copied as such to the final .pot file. I have tried to do a mock build
with all files from the /po directory ( but fr.po ) removed, but configure
failed with:
  checking for msgfmt... /usr/bin/msgfmt
  checking for gmsgfmt... /usr/bin/msgfmt
  checking for xgettext... /usr/bin/xgettext
  checking for msgmerge... /usr/bin/msgmerge
  configure: creating ./config.status
  config.status: creating Makefile
  config.status: error: cannot find input file: po/Makefile.in.in
I've also tried builds after adding this file but independent of the presence of
BR:gettext they fail with
  Making all in po
  make[2]: Entering directory `/builddir/build/BUILD/gpar2-0.3/po'
  make[2]: *** No rule to make target `all'.  Stop.
  make[2]: Leaving directory `/builddir/build/BUILD/gpar2-0.3/po'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/builddir/build/BUILD/gpar2-0.3'
  make: *** [all] Error 2
  error: Bad exit status from /var/tmp/rpm-tmp.45363 (%build)



Both my configure-foo and my po-management skills are rather weak so I do not
feel like digging deeper.
However this makes me a bit uneasy because in this moment I really do not know
what would be the proper solution. As far as I see, we have the following
options, listed from ugliest to preferred :
1) Patch configure to drop the fr.po completely.
2) Leave it as it is. Unfortunately I think that this approach violates
http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90
"For several reasons, a package should not include or build against a local copy
of a library that exists on a system. The package should be patched to use the
system libraries." However in this case the culprit is not a library but an
executable. Does the  above guideline still apply ? In order to respect the
meaning (and not the letter), I would say "yes, it still applies" but I am more
then willing to stand corrected if I am wrong.
3) Patch configure to really use the system wide gettext instead of the private
copy.




-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-package-review

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]