Not sure this needs a formal review, but I can do so if need be. 

Questions/Issues: 

1. What are these for? upstream/old packages? 

Obsoletes:      %{origname} <= %{version}-%{release}
Provides:       %{origname} = %{version}-%{release}
Obsoletes:      twisted <= %{version}-%{release}
Provides:       twisted = %{version}-%{release}

2. Should both of those Obsoletes be just "<" and not "<=" ? 
Surely you don't want to obsolete the very version you are providing? 

3. Note that the old python-twisted package has: 
Obsoletes: python-Twisted < 1.3.0
Provides: python-Twisted = %{version}-%{release}

Should that be carried forward? 

Can any Obsolete/Provides/Metapackage savvy folks look this over? 

I think you're right, in fact the obsoletes should obsolete a specified version,
not "below current" for a name change.

The old ones needn't be carried over, they were only my private packages.  The
others listed are from other repos that asked me to put them in there.

New version at
http://thomas.apestaart.org/download/pkg/fedora-5-i386-extras/python-twisted-2.4.0-2.fc5/

OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
OK - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License (MIT)
OK - License field in spec matches
OK - Spec in American English
OK - Spec is legible.
OK - BuildRequires correct
OK - Package has %defattr and permissions on files is good. 
OK - Package has a correct %clean section.
OK - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
OK - No rpmlint output.
OK - final provides and requires are sane:

SHOULD Items:

OK - Should build in mock.
OK - Should build on all supported archs
OK - Should have dist tag

Issues:

1. The README.fedora is a bit on the terse side.
You might have it list out the other packages that this one
pulls in or at least repeat the summary, but thats not a
big deal or a blocker.

I think the obsoletes and provides are correct here.
I tried to upgrade a fc6 python-twisted with this version
and it correctly pulled in the packages and installed.

I did notice one install on removal of any of the python-twisted-*
packages that did the /usr/libexec/twisted-dropin-cache call in
postun. If you remove them and python-twisted-core, rpm
removes python-twisted-core first, resulting in a failed scriptlet
on the other package, ie:

rpm -e python-twisted-core python-twisted-words
error: %postun(python-twisted-words-0.4.0-3.fc6.i386) scriptlet failed, exit
status 255

I think those packages need a
Requires(postun): python-twisted-core

I see no issues with this meta package, so I would be
happy to APPROVE it.

Don't forget to close this NEXTRELEASE once it's been imported
and built. Also, once it's been pushed to fc6, you should be able to
rebuild flumotion there and hopefully fix the broken fc5->fc6
upgrade path in it.

(In reply to comment #3)
> I did notice one install on removal of any of the python-twisted-*
> packages that did the /usr/libexec/twisted-dropin-cache call in
> postun. If you remove them and python-twisted-core, rpm
> removes python-twisted-core first, resulting in a failed scriptlet
> on the other package, ie:
> 
> rpm -e python-twisted-core python-twisted-words
> error: %postun(python-twisted-words-0.4.0-3.fc6.i386) scriptlet failed, exit
> status 255
> 
> I think those packages need a
> Requires(postun): python-twisted-core

I think there are already implicit dependencies present for these, which come
about through using the scriptlet form:

%postun -p %{_libexecdir}/twisted-dropin-cache

This results in scriptlet dependencies on %{_libexecdir}/twisted-dropin-cache,
which implies python-twisted-core. So I don't know why rpm is removing the core
package first.

In reply to comment #4: 

Yeah, the dependencies are there... I see whats happening now. 
It's the twisted-dropin-cache scriptlet returning 255 in that situation. 
python-twisted-core is still there when the other package is removed. 

So, it looks like it's a bug of some kind in that twisted-dropin-cache
scriptlet. 

I'll file a bug against python-twisted-core, since this is off topic for this
metapackage review. ;) 

I see that Twisted 2.5.0 is out now, and claims to support python 2.5 (the
release notes say that previous versions were broken with python 2.5). Given
that Rawhide has python 2.5, I think that 2.5.0 should be pushed at least for devel.

Kevin, do you know how I can reproduce the problem you are seeing ?

(In reply to comment #3)
> I did notice one install on removal of any of the python-twisted-*
> packages that did the /usr/libexec/twisted-dropin-cache call in
> postun. If you remove them and python-twisted-core, rpm
> removes python-twisted-core first, resulting in a failed scriptlet
> on the other package, ie:
> 
> rpm -e python-twisted-core python-twisted-words
> error: %postun(python-twisted-words-0.4.0-3.fc6.i386) scriptlet failed, exit
> status 255

Interesting. This occurs on FC6, but not on FC-devel.
Maybe rpm has some issues.

* Tue Nov 21 2006 Paul Nasrat <pnasrat> - 4.4.2-36
- Fix ordering issues (#196590)

* Wed Nov 01 2006 Paul Nasrat <pnasrat> - 4.4.2-35
- Flush query buffer patch from jbj (#212833)

* Wed Nov 01 2006 Paul Nasrat <pnasrat> - 4.4.2-34
- Debuginfo extraction with O0

* Thu Oct 26 2006 Paul Nasrat <pnasrat> - 4.4.2-33
- Fix for ordering (#202540, #202542, #202543, #202544)

  Maybe some change occured in -33 and -36 fixed this
  problem.

Created attachment 145667 [details]
remove test log on FC-devel

The log of
------------------------------------
rpm -evv --test python-twisted-core python-twisted-words
------------------------------------
on FC-devel.

This log says that removing will be done by the
order of "words->core"

Created attachment 145668 [details]
remove test log on FC-6

Same on FC-6.

The log says "core->words"

We can continue discussion of this bug over in: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222013

I just posted at least what could be a workaround for rpm in fc6. 

(In reply to comment #3)
> I see no issues with this meta package, so I would be
> happy to APPROVE it.

Well, I also think that there is nothing which this metapackage
should fix for scriptlet ordering issue and this package
may go.

pushed for devel and fc6, closing