Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=608326 --- Comment #5 from Kalev Lember <kalev@xxxxxxxxxxxx> 2010-07-06 12:25:55 EDT --- Thanks for the review. (In reply to comment #3) > ! The file ChangeLog can go to devel package, as we have the user-friendly > NEWS file in the main package. I am not sure if it's such a good idea; it's difficult for people to look up things if docs are cluttered all over in different directories: /usr/share/doc/gtkmm30-2.90.4.0/NEWS /usr/share/doc/gtkmm30-devel-2.90.4.0/ChangeLog Anyway, I revised the docs in -devel package and removed PORTING file, which was largely useless. That leaves us with only: %doc demos/gtk-demo/ in -devel package. I wonder if it'd be better to move gtk-demo to -doc package too, so that most docs (including NEWS and ChangeLog) are in main package, -devel package contains no docs, and API docs + demos are in -doc package? > ? Is it possible to run the tests in the tests/ directory in a %check section? > Or should we include them in the devel package? Ah, very good catch. Added it to the %check section. > * Package name is odd. Actually the whole gtk related packages have weird > names. I see that they didn't pass the merge review yet, that's probably why. > Since there is no package called gtkmm, can we call this package simply gtkmm, > so that we can stay more consistent with the guidelines? I think it's less confusing to name it gtkmm30. Very different from most packages, gtk stack is designed to be parallel installable from the ground up. - link-libraries have 3.0 in their names: /usr/lib/libgdkmm-3.0.so /usr/lib/libgtkmm-3.0.so - pkgconfig files have 3.0 in their names: /usr/lib/pkgconfig/gdkmm-3.0.pc /usr/lib/pkgconfig/gtkmm-3.0.pc - headers are in versioned directory: /usr/include/gtkmm-3.0/ When for most packages major version upgrades come naturally, then for gtkmm people need to explicitly port their apps to use the new API: link-library names, pkgconfig file names, and include directories have all changed. Lets say there will be gtkmm 3.0, 3.2, 3.4, and 3.6 releases with 3.0 API. After that comes gtkmm 3.8 API: gtkmm38-3.8, gtkmm38-3.10, gtkmm38-3.12, and so on. As I said before, upstreams need to explicitly port their apps to use next API. That means if we named this package (API version 3.0) to just "gtkmm", we'll still need to name the package of the next API version "gtkmm38". Look at the package list we have: gtkmm20 gtkmm24 gtkmm <--- this one looks off gtkmm38 I really think it's easier for end users to use gtkmm30 package name here. Besides, I tried to look up the review request ticket for gtkmm20 but couldn't find it, grr. Wonder what has happened to it. Any idea what's this "fedora bug 727"? From gtkmm24 spec: * Sat Oct 4 2003 Michael Koziarski <michael@xxxxxxxxxxxxx> - 0:2.2.8-0.fdr.1 - Incorporated Michael Schwendt's Comments in fedora bug 727 Also, the same spec file indicates that there was gtkmm package once: * Mon Oct 14 2002 Gary Peck <gbpeck@xxxxxxxxxxxxx> - 1.3.24-gp1 - Initial release of gtkmm2, using gtkmm spec file as base > * There is a problem with license. We have a file called COPYING.tools (GPLv2), > which suggests that the tools/ directory is GPLv2. Indeed when we look at > tools/extra_defs_gen/generate_defs_gtk.cc we see that it is licensed GPLv2+. > However this file does not get installed. On the other hand, the contents of > the directory tools/m4 get installed. Unfortunately, these files do not > indicate a license. Are these files GPL or LGPL? This needs to be clarified by > upstream. Talked with upstream and this has been clarified to be LGPL: https://bugzilla.gnome.org/show_bug.cgi?id=623681 > * Macro issue: We should use %{_datadir} instead of /usr/share Fixed. I should really dig into the build scripts and figure out something sane instead of resorting to all this sed magic. > - Requires: pkgconfig is missing in the devel package. However this is not a > problem if the package will be Fedora only. Yes, it will be rawhide-only. (In reply to comment #4) > gtkmm30.src: W: invalid-url Source0: > http://ftp.gnome.org/pub/GNOME/sources/gtkmm/2.90.4.0./gtkmm-2.90.4.0.tar.bz2 > HTTP Error 404: Not Found Fixed. Looks like changing %global to %define makes rpmlint shut up here. > gtkmm30.x86_64: W: spelling-error %description -l en_US typesafe -> type > safe, type-safe, typeset Fixed. I also updated the whole description, which wasn't very readable, so please reread that. > gtkmm30.x86_64: E: binary-or-shlib-defines-rpath > /usr/lib64/libgtkmm-3.0.so.1.1.0 ['/usr/lib64'] Fixed. > ! Please make the description span 80 columns as much as possible. Currently > it is set to 70 columns. I did that and then changed back again after rewording the description. I have nothing against 80 columns per se, it's just that the right edge gets too jagged with 80 columns and it's easier to read it like it is now. > ! BRs: cairomm-devel and glibmm24-devel seem redundant. They get pulled it by > other dependencies. They don't cause any harm though. Didn't change that. gtkmm's configure script looks explicitly for those two, so I'd rather keep the buildrequires instead of hoping that some other packages pull those in. > ! The package gtk-doc is listed as a dependency for directory ownership. /.../ Thanks, will keep an eye on the draft. -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review