Bug 166054
Summary: | Review Request: gtkmathview - Addition of gtkmathview to Extras | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Marc Maurer <uwog> |
Component: | Package Review | Assignee: | Gérard Milmeister <gemi> |
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, rdieter |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.abisource.com/~uwog/gtkmathview/gtkmathview-0.7.3-1.src.rpm | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-08-30 22:50:04 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779 |
Description
Marc Maurer
2005-08-16 13:02:13 UTC
* Missing BuildRequires: At least gtk2-devel, t1lib-devel, zlib-devel, maybe a few others * If development files from other packages are needed to build using gtkmathview-devel, they should be indicated in the Requires: tag of gtkmathview-devel, e.g. Requires: gtk2-devel * What about gmetadom? * There are manpages for mathml2ps and mathmlviewer but no binaries, do not include them * %doc should include CONTRIBUTORS BUGS LICENSE * The Description: section for the main package should be more extended IMHO Thanks Gérard... I don't know why I missed that all; must have been tired :-/ Your suggestions found their way in a new spec: http://www.abisource.com/~uwog/gtkmathview/gtkmathview.spec SRPM available here: http://www.abisource.com/~uwog/gtkmathview/gtkmathview-0.7.3-2.src.rpm Drop the explicit Requires: Requires: glib2 >= 2.2.1 Requires: gtk2 >= 2.2.1 Requires: libxml2 >= 2.6.7 Requires: popt >= 1.7.0 The Description is one long line. Insert some line breaks to make the line length at most 70. You don't need "--disable-gmetadom --without-t1lib" if it builds without them. However the question is: is the functionality reducted because of missing gmetadom and t1lib. If yes then maybe packages for both these libraries should be created. The manpage /usr/share/man/man1/mathmlviewer.1.gz needs also to be removed. OK, thesis is done, time to get back on this :-) @Rex Dieter: why would one want to drop the Requires? @Gérard: Description is fixed now. The GMetaDom is (iirc) very experimental right now, is I think it is best to disable it. I'll ask the maintainer for details. t1lib is only needed to load Type1 fonts, but all important fonts (the Computer Modern familily) are available as True Type Fonts. I'll invesitgate the need for Type 1 fonts, we can always enable it if we want t1lib in Extras as well. I dropped the -disable-gmetadom --without-t1lib options, it builds fine without them. Deleted the mathmlviewer.1 manpage too... I thought I built the accompanying binary, but I was mistaken it with mathmlsvg :-/ New spec: http://www.abisource.com/~uwog/gtkmathview/gtkmathview.spec New SRPM: http://www.abisource.com/~uwog/gtkmathview/gtkmathview-0.7.3-3.src.rpm > @Rex Dieter: why would one want to drop the Requires?
Because they're not needed. rpm will autodetect these.
But that assumes that the proper versions are in rawhide. Now i know this is the case, but I love extra security... But i can drop them if you insist/ IIRC, freetype also handles type 1 fonts, so t1lib isn't necessary. Explicit Requires: on libraries such as gtk+ is *strongly* discouraged. It causes more problems than it solves. If a package builds on a platform, but then requires a specific version of gtk2, something is wrong and should be fixed. Well, additional functions have been added to every stable gtk2 release, so requiring >= 2.2 is really needed. Is that allowed? If a package builds on, say, rawhide, the resulting rpm will have the correct requires for rawhide, namely libgtk-x11-2.0.so.0, etc. So it will be installed on exactly the same configuration, that it is built on. If someone installs on a different platform (fedora, or not) that has libgtk-x11-2.0.so.0, but is not the exact required version, than it is his on responsability, and is not supported at all. It may happen, that an update to, say, gtk2 breaks the package dependent on it. But then the package must be rebuilt as soon as possible. The version of a package is always the version of latest update. > Is that allowed?
It's overly pedantic and ties your main binary package against a list
of specific package names and versions. Makes it more complicated to
move a needed library into a different package without rebuilding your
one as well. Also, the question ought to be "Does it make sense?",
because Gtk+ >= 2.2 and GLib >= 2.2.1 are available for all the Fedora Core
versions you target. Finally, do you want to guarantee that your binaries
really work with any package named gtk2-2.2.1-something even if you
built it for gtk2-2.8.0-something?
There are special cases when an explicit dependency on package names and
versions makes sense in addition to an automatic dependency on SONAMEs.
Thanks for the explanations. New spec and SRPM here: Spec: http://www.abisource.com/~uwog/gtkmathview/gtkmathview.spec SRPM: http://www.abisource.com/~uwog/gtkmathview/gtkmathview-0.7.3-4.src.rpm Still includes uneeded: Requires: glib2 Requires: gtk2 Requires: libxml2 Sorry about that. Apparently the automation is further along than I expected in the rpm build world :) Spec: http://www.abisource.com/~uwog/gtkmathview/gtkmathview.spec SRPM: http://www.abisource.com/~uwog/gtkmathview/gtkmathview-0.7.3-5.src.rpm Marc, have you got an account? If not, you should go to https://admin.fedora.redhat.com/accounts. I think you also need a sponsor. Yes, I'm a fedora extras maintainer already (abiword,link-grammar,aiksaurus, etc) Does that mean the spec is approved? :) Everything looks allright to me. Normalize summary field for easy parsing |