Spec URL: http://people.redhat.com/mclasen/pygtksourceview/pygtksourceview.spec SRPM URL: http://people.redhat.com/mclasen/pygtksourceview/pygtksourceview-1.90.1-1.fc8.src.rpm Description: This package contains file required to build Python programs that use the %{name} bindings.
You missspelted pgkconfig
The -devel description says "file" where it should say "files"
you ship .la files in the package. We don't do them here do we ?
Other than those small issues, seems to look pretty good. Ship it!
New Package CVS Request ======================= Package Name: pygtksourceview Short Description: Python bindings for gtksourceview Owners: mbarnes, mclasen Branches: InitialCC:
cvs done. Aside from the .la issue, Any reason you aren't using %{?_smp_mflags} with your make?
Related to the gtksourceview update, and the new bindings, we found that we need to reinstate the v1.x gtksourceview package, since a few apps and libs require it, and 2.x is not api/abi compatible. New Package CVS Request ======================= Package Name: compat-gtksourceview Short Description: gtksourceview v1.x Owners: rstrode Branches: InitialCC:
Can you file a new review for that package? I know it was in before, but it's good to run it through a quick review and make sure it doesn't conflict with the new one, etc.
No, please. The package was in before, there is a merge review ticket for it too. Don't make me just through more hoops than necessary. I'll take care of resolving any conflicts before building the package.
If someone points me to the package that needs reviewing, I'll review it. Chances are I already have it checked out of CVS somewhere.
There is no package here that needs reviewing.
(In reply to comment #9) > No, please. > > The package was in before, there is a merge review ticket for it too. > Don't make me just through more hoops than necessary. I'll take care of > resolving any conflicts before building the package. I realize that it may seem like hoop jumping to have to put through review a package which was already in the distribution. And if that was the case, then it definitely would be. Unfortunately, a compat-* package is a new package with new requirements. As you note, there can be conflicts that arise from such a package that need to be resolved before building and pushing it into the repository with the non-compat version. Resolving the immediate source of filesystem conflicts can sometimes require patching source to look in different directories as well. With C libraries, header files and other development bits may be pruned out. A compat-* package is a different beast from the normal package that spawns it. You're an experienced enough packager that your first stab at a package will probably be excellent. You have an excellent reviewer in tibbs lined up and ready to review it. So there won't be much holdup between the time you submit and the time it hits the repository. That may tempt you into thinking a compat-* package is trivial and the review mere bureaucracy. But think for a moment of what happens when we have other, less experienced packagers, submitting compat-* packages. Experience with compat-* packages in Extras has shown that even moderately experienced packagers tend to forget some things when packaging compat-* packages for the simple reason that they have special caveats that are different from the non-compat packages those packagers are used to creating. We need the review step to help catch these problems.
Blargh. Don't call it compat-gtksourceview then, call it gtksourceview1, and make it a full package. Suddenly no special, secret compat- requirements anymore.
Looking at what I suppose are the involved files (no way to tell for sure, since there is no package posted to look at) it looks like gtksourceview1 *is* a better name. You are planning to package gtksourceview1 and gtksourceview1-devel so that apps can build, correct? This situation is more akin to gtk+ vs gtk2 than compat-libstc++. That aside, this isn't about the compat-* name having "secret requirements". It's about the nature of packaging two separate versions of a library and installing them onto one system. For gtksourceview which (as I look at the gtksourceview package that I assume you'll be basing off of) appears to have installed to versioned directories in version1 as well as version2, doesn't have any programs, etc, there shouldn't be any problems. You probably won't even be tempted to get cute with your Provides: as you're experienced enough to avoid those pitfalls. But 1) There's no way that I can know that the gtksourceview code makes it easy to parallel install these libraries without having a package to review. 2) Even if I'm resourceful enough to grab an older gtksourceview there's no way I can know that what I'm looking at in this gtksourceview package is what you propose as the base of your import because you may have to fix it up for conflicts, etc. 3) It's not the job of the cvsadmin to review packaging. If they want to, that's great but really you can only count on them to process cvs requests. If something's fishy (like no review for a package and no srpm to even look at) they have no way of knowing whether to approve it or not so chances are they'll err on the side of safety. Getting a review is going to speed the acceptance process.
Acutally, since compat- naming seems to invoke the wrong expectations in people, the best solution is to reinstate the v1 gtksourceview with an epoch, and move v2 to a new gtksourceview2 package. That way packages depending on v1 don't have to change their requires. Of course, now you will call for a review of gtksourceview2 instead of gtksourceview1... Anyway, I've had enough of this for today
There you go: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246046
Package Change Request ====================== Package Name: pygtksourceview Branches: OLPC-2 Owners: chris.net, johnp