Bug 245597 - Review Request: pygtksourceview - Python bindings for gtksourceview
Review Request: pygtksourceview - Python bindings for gtksourceview
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-25 12:59 EDT by Matthias Clasen
Modified: 2008-07-10 14:24 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-10 14:24:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rstrode: fedora‑review+
kevin: fedora‑cvs-


Attachments (Terms of Use)

  None (edit)
Description Matthias Clasen 2007-06-25 12:59:23 EDT
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.
Comment 1 Ray Strode [halfline] 2007-06-26 11:39:59 EDT
You missspelted pgkconfig
Comment 2 Ray Strode [halfline] 2007-06-26 12:33:28 EDT
The -devel description says "file" where it should say "files"
Comment 3 Ray Strode [halfline] 2007-06-26 12:35:16 EDT
you ship .la files in the package.  We don't do them here do we ?
Comment 4 Ray Strode [halfline] 2007-06-26 13:45:40 EDT
Other than those small issues, seems to look pretty good.   Ship it!
Comment 5 Matthias Clasen 2007-06-26 14:05:49 EDT
New Package CVS Request
=======================
Package Name: pygtksourceview 
Short Description: Python bindings for gtksourceview
Owners: mbarnes@redhat.com, mclasen@redhat.com
Branches: 
InitialCC: 
Comment 6 Kevin Fenzi 2007-06-26 14:56:13 EDT
cvs done. 

Aside from the .la issue, Any reason you aren't using %{?_smp_mflags} with your
make?
Comment 7 Matthias Clasen 2007-06-27 13:09:23 EDT
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@redhat.com
Branches: 
InitialCC: 
Comment 8 Kevin Fenzi 2007-06-27 16:10:13 EDT
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. 
Comment 9 Matthias Clasen 2007-06-27 16:20:18 EDT
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.
Comment 10 Jason Tibbitts 2007-06-27 16:54:47 EDT
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.
Comment 11 Matthias Clasen 2007-06-27 17:34:16 EDT
There is no package here that needs reviewing.
Comment 12 Toshio Kuratomi 2007-06-27 18:20:27 EDT
(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.
Comment 13 Matthias Clasen 2007-06-27 18:34:23 EDT
Blargh. Don't call it compat-gtksourceview then, call it gtksourceview1, and
make it a full package. Suddenly no special, secret compat- requirements anymore.
Comment 14 Toshio Kuratomi 2007-06-27 20:31:42 EDT
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.
Comment 15 Matthias Clasen 2007-06-27 21:01:40 EDT
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
Comment 16 Matthias Clasen 2007-06-27 21:53:03 EDT
There you go: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246046
Comment 17 Chris Ball 2007-08-16 19:24:29 EDT
Package Change Request
======================
Package Name: pygtksourceview
Branches: OLPC-2
Owners: chris@void.printf.net, johnp@redhat.com

Note You need to log in before you can comment on or make changes to this bug.