Migrating sub-package to a different package: How to resolve file conflicts

[Tom Stellard]

Hi,

I'm working on moving the llvm-devel sub-package from the llvm package to
a new llvm4.0 package, however, when I upgrade from the llvm sub-package
to the llvm4.0 sub-package, I am getting file conflicts.

This can be reproduced on rawhide with these commands:

[root@746864b6a202 /]#  dnf install llvm-devel
[root@746864b6a202 /]#  dnf install 'dnf-command(copr)'
[root@746864b6a202 /]#  dnf copr enable tstellar/llvm-versioned
[root@746864b6a202 /]#  dnf install llvm-devel-4.0.0-13.fc27

Here is the error:

Error: Transaction check error:
  file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64 conflicts with
file from package llvm-devel-4.0.0-4.fc27.x86_64
  file /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64 conflicts with
file from package llvm-devel-4.0.0-4.fc27.x86_64

I don't understand how a package can conflict with on older version of
the same package.  Here are the spec files:

llvm-devel-4.0.0-13.fc27.x86_64:
http://copr-dist-git.fedorainfracloud.org/cgit/tstellar/llvm-versioned/ll...
llvm-devel-4.0.0-4.fc27.x86_64:
https://src.fedoraproject.org/cgit/rpms/llvm.git/tree/llvm.spec

Is this a bug in dnf/rpm or am I doing something wrong with the spec files?


-Tom

[Matthew Miller]

On Mon, Jun 12, 2017 at 05:01:19PM -0400, Tom Stellard wrote:
>  Hi,
>  
>  I'm working on moving the llvm-devel sub-package from the llvm package to
>  a new llvm4.0 package, however, when I upgrade from the llvm sub-package
>  to the llvm4.0 sub-package, I am getting file conflicts.
>  
>  This can be reproduced on rawhide with these commands:
>  
>  [root@746864b6a202 /]#  dnf install llvm-devel
>  [root@746864b6a202 /]#  dnf install 'dnf-command(copr)'
>  [root@746864b6a202 /]#  dnf copr enable tstellar/llvm-versioned
>  [root@746864b6a202 /]#  dnf install llvm-devel-4.0.0-13.fc27 
You'll have to install the devel package at the same time you update to
the new version of the base package. (Fortunately, DNF now again
follows the yum convention of translating install to upgrade when you
are asking to install an updated package.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Tom Stellard]

On 06/12/2017 05:22 PM, Matthew Miller wrote:
>  On Mon, Jun 12, 2017 at 05:01:19PM -0400, Tom Stellard wrote:
> > Hi,
> >
> > I'm working on moving the llvm-devel sub-package from the llvm package to
> > a new llvm4.0 package, however, when I upgrade from the llvm sub-package
> > to the llvm4.0 sub-package, I am getting file conflicts.
> >
> > This can be reproduced on rawhide with these commands:
> >
> > [root@746864b6a202 /]#  dnf install llvm-devel
> > [root@746864b6a202 /]#  dnf install 'dnf-command(copr)'
> > [root@746864b6a202 /]#  dnf copr enable tstellar/llvm-versioned
> > [root@746864b6a202 /]#  dnf install llvm-devel-4.0.0-13.fc27
>  
>  You'll have to install the devel package at the same time you update to
>  the new version of the base package. (Fortunately, DNF now again
>  follows the yum convention of translating install to upgrade when you
>  are asking to install an updated package.
>  
>   
The old base package: 'llvm' is being deprecated and is being moved
into 'llvm4.0' as a sub-package. For example:

Before:
+llvm
  - llvm
  - llvm-devel
  - llvm-libs
  - llvm-static
  - llvm-doc

After:

+ llvm (deprecated)

+llvm4.0:
   -llvm4.0
  - llvm4.0-devel
  - llvm4.0-libs
  - llvm
  - llvm-devel
  - llvm-libs
  - llvm-static
  - llvm-doc


-Tom

[Neal Gompa]

On Mon, Jun 12, 2017 at 5:34 PM, Tom Stellard <tstellar(a)redhat.com&gt; wrote:
>  On 06/12/2017 05:22 PM, Matthew Miller wrote:
> > On Mon, Jun 12, 2017 at 05:01:19PM -0400, Tom Stellard wrote:
> >> Hi,
> >>
> >> I'm working on moving the llvm-devel sub-package from the llvm package to
> >> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
> >> to the llvm4.0 sub-package, I am getting file conflicts.
> >>
> >> This can be reproduced on rawhide with these commands:
> >>
> >> [root@746864b6a202 /]#  dnf install llvm-devel
> >> [root@746864b6a202 /]#  dnf install 'dnf-command(copr)'
> >> [root@746864b6a202 /]#  dnf copr enable tstellar/llvm-versioned
> >> [root@746864b6a202 /]#  dnf install llvm-devel-4.0.0-13.fc27
> >
> > You'll have to install the devel package at the same time you update to
> > the new version of the base package. (Fortunately, DNF now again
> > follows the yum convention of translating install to upgrade when you
> > are asking to install an updated package.
> >
> >
>
>  The old base package: 'llvm' is being deprecated and is being moved
>  into 'llvm4.0' as a sub-package. For example:
>
>  Before:
>  +llvm
>    - llvm
>    - llvm-devel
>    - llvm-libs
>    - llvm-static
>    - llvm-doc
>
>  After:
>
>  + llvm (deprecated)
>
>  +llvm4.0:
>     -llvm4.0
>    - llvm4.0-devel
>    - llvm4.0-libs
>    - llvm
>    - llvm-devel
>    - llvm-libs
>    - llvm-static
>    - llvm-doc
>  
Why? What's the compelling reason to do this? And if we're doing this
to llvm, are we going to do this to gcc, too?



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Tom Stellard]

On 06/12/2017 05:41 PM, Neal Gompa wrote:
>  On Mon, Jun 12, 2017 at 5:34 PM, Tom Stellard
> <tstellar(a)redhat.com&gt; wrote:
> > On 06/12/2017 05:22 PM, Matthew Miller wrote:
> >> On Mon, Jun 12, 2017 at 05:01:19PM -0400, Tom Stellard wrote:
> >>> Hi,
> >>>
> >>> I'm working on moving the llvm-devel sub-package from the llvm package
> to
> >>> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
> >>> to the llvm4.0 sub-package, I am getting file conflicts.
> >>>
> >>> This can be reproduced on rawhide with these commands:
> >>>
> >>> [root@746864b6a202 /]#  dnf install llvm-devel
> >>> [root@746864b6a202 /]#  dnf install 'dnf-command(copr)'
> >>> [root@746864b6a202 /]#  dnf copr enable tstellar/llvm-versioned
> >>> [root@746864b6a202 /]#  dnf install llvm-devel-4.0.0-13.fc27
> >>
> >> You'll have to install the devel package at the same time you update to
> >> the new version of the base package. (Fortunately, DNF now again
> >> follows the yum convention of translating install to upgrade when you
> >> are asking to install an updated package.
> >>
> >>
> >
> > The old base package: 'llvm' is being deprecated and is being moved
> > into 'llvm4.0' as a sub-package. For example:
> >
> > Before:
> > +llvm
> >   - llvm
> >   - llvm-devel
> >   - llvm-libs
> >   - llvm-static
> >   - llvm-doc
> >
> > After:
> >
> > + llvm (deprecated)
> >
> > +llvm4.0:
> >    -llvm4.0
> >   - llvm4.0-devel
> >   - llvm4.0-libs
> >   - llvm
> >   - llvm-devel
> >   - llvm-libs
> >   - llvm-static
> >   - llvm-doc
> >
>  
>  Why? What's the compelling reason to do this? And if we're doing this
>  to llvm, are we going to do this to gcc, too?
>  
>  
>   
I want to make it possible to have multiple versions of the LLVM
libraries installed at the same time.  The reason for this is that
all the various packages that depend on LLVM don't all have their
upstream move to the newest version at the same time.  This makes it
very difficult to get new versions of clang into Fedora, because we
get blocked until all the other packages (e.g. pocl, beignet, rust, etc.)
get support upstream for the latest version of LLVM.

My idea was to have separate llvm4.0, llvm5.0, llvm6.0, etc packages that
provided the versions libs, and I would like to have a llvm metapackage that
will pull in the most recent llvmX.0 package. I thought it would be easiest
to have the llvm-* packages as sub-packages of llvmX.0, because then I could
still have unversioned packages for things like static libs, all part
of a single build.

I thought bundling llvm-* sub-packages in llvmX.0 would be easiest, but
it's not something that is a requirement for me.  My main goal is to have
multiple LLVM versions installed at once.

No plans to do this for gcc, because gcc is only compiler not a library,
like LLVM, though I would like to do this for the clang libraries as well.

-Tom

[Florian Weimer]

On 06/13/2017 12:49 AM, Tom Stellard wrote:
>  No plans to do this for gcc, because gcc is only compiler not a
> library,
>  like LLVM, though I would like to do this for the clang libraries as well. 
GCC potentially has similar issues.  However, libstdc++ aims at
backwards compatibility, and the other ABIs (the plug-in host, the other
language run-time library) only have few users, and ABI transitions are
traditionally handled as part of distribution rebuilds.

Thanks,
Florian

[Rex Dieter]

Tom Stellard wrote:

>  I'm working on moving the llvm-devel sub-package from the llvm
> package to
>  a new llvm4.0 package, however, when I upgrade from the llvm sub-package
>  to the llvm4.0 sub-package, I am getting file conflicts. 
...
>  Error: Transaction check error:
>    file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>    conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>    /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>    conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 
>  Is this a bug in dnf/rpm or am I doing something wrong with the spec
>  files? 
IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to 
implicitly Obsoletes/replace older packages of the same name (in general, 
though there are exceptions like "kernel")

-- Rex

[Rex Dieter]

Rex Dieter wrote:

>  Tom Stellard wrote:
>  
> > I'm working on moving the llvm-devel sub-package from the llvm package to
> > a new llvm4.0 package, however, when I upgrade from the llvm sub-package
> > to the llvm4.0 sub-package, I am getting file conflicts.
>  ...
> > Error: Transaction check error:
> >   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
> >   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
> >   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
> >   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
>  
> > Is this a bug in dnf/rpm or am I doing something wrong with the spec
> > files?
>  
>  IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to
>  implicitly Obsoletes/replace older packages of the same name (in general,
>  though there are exceptions like "kernel") 
Occurs to me you could avoid/skip relying on the implicit replacement, and 
make it *explicit*, but adding
Obsoletes: llvm-devel < 4.0.0-13
to the new llvm-devel subpkg

-- Rex

[Neal Gompa]

On Tue, Jun 13, 2017 at 10:25 AM, Rex Dieter <rdieter(a)math.unl.edu&gt; wrote:
>  Rex Dieter wrote:
>
> > Tom Stellard wrote:
> >
> >> I'm working on moving the llvm-devel sub-package from the llvm package to
> >> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
> >> to the llvm4.0 sub-package, I am getting file conflicts.
> > ...
> >> Error: Transaction check error:
> >>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
> >>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
> >
> >> Is this a bug in dnf/rpm or am I doing something wrong with the spec
> >> files?
> >
> > IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to
> > implicitly Obsoletes/replace older packages of the same name (in general,
> > though there are exceptions like "kernel")
>
>  Occurs to me you could avoid/skip relying on the implicit replacement, and
>  make it *explicit*, but adding
>  Obsoletes: llvm-devel < 4.0.0-13
>  to the new llvm-devel subpkg
>  
Implicit replacements are dangerous, and lead to weird special cases.
It's far better to be explicit. I woudl argue that this was actually a
Yum bug that people turned into a misfeature, and we should adjust and
actually be explicit about when content changes so Obsoletes need to
be in place. DNF already handles most of the YumObsoletes behavior,
but implicit replacements are tricky.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Rex Dieter]

Neal Gompa wrote:

>  Implicit replacements are dangerous, and lead to weird special cases.
rpm handles it (rpm --upgrade ...), dnf should do the same.  This is not 
just a special case, but a very simple one that's always worked.   IMHO

-- Rex

[Tom Stellard]

On 06/13/2017 10:25 AM, Rex Dieter wrote:
>  Rex Dieter wrote:
>  
> > Tom Stellard wrote:
> >
> >> I'm working on moving the llvm-devel sub-package from the llvm package to
> >> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
> >> to the llvm4.0 sub-package, I am getting file conflicts.
> > ...
> >> Error: Transaction check error:
> >>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
> >>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
> >
> >> Is this a bug in dnf/rpm or am I doing something wrong with the spec
> >> files?
> >
> > IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to
> > implicitly Obsoletes/replace older packages of the same name (in general,
> > though there are exceptions like "kernel")
>  
>  Occurs to me you could avoid/skip relying on the implicit replacement, and 
>  make it *explicit*, but adding
>  Obsoletes: llvm-devel < 4.0.0-13
>  to the new llvm-devel subpkg
>   
I just tried this, but I still get the same error as before.  Could there
be some other issue?

Here is the updated spec file:
http://copr-dist-git.fedorainfracloud.org/cgit/tstellar/llvm-versioned/ll...

-Tom

[Matthew Miller]

On Tue, Jun 13, 2017 at 02:40:27PM -0400, Tom Stellard wrote:
>  >>> Error: Transaction check error:
>  >>>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>  >>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>  >>>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>  >>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
[...]
>  I just tried this, but I still get the same error as before.  Could
> there
>  be some other issue? 
Are all of the dependencies of the old llvm-devel package filled if you have
the new llvm-devel installed? My assumption is that this is happening
not because of any problem with obsoleting, but that DNF needs the old
package to stay to keep some dependency filled.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Tom Stellard]

On 06/13/2017 02:51 PM, Matthew Miller wrote:
>  On Tue, Jun 13, 2017 at 02:40:27PM -0400, Tom Stellard wrote:
> >>>> Error: Transaction check error:
> >>>>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
> >>>>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
>  [...]
> > I just tried this, but I still get the same error as before.  Could there
> > be some other issue?
>  
>  Are all of the dependencies of the old llvm-devel package filled if you have
>  the new llvm-devel installed? My assumption is that this is happening
>  not because of any problem with obsoleting, but that DNF needs the old
>  package to stay to keep some dependency filled.
>   
It's possible, is there a good way to debug this?

-Tom

[Tom Stellard]

On 06/13/2017 02:51 PM, Matthew Miller wrote:
>  On Tue, Jun 13, 2017 at 02:40:27PM -0400, Tom Stellard wrote:
> >>>> Error: Transaction check error:
> >>>>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
> >>>>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
>  [...]
> > I just tried this, but I still get the same error as before.  Could there
> > be some other issue?
>  
>  Are all of the dependencies of the old llvm-devel package filled if you have
>  the new llvm-devel installed? My assumption is that this is happening
>  not because of any problem with obsoleting, but that DNF needs the old
>  package to stay to keep some dependency filled.
>   
Here is the output I get with --debuglevel=1

--> Starting dependency resolution
---> Package llvm4.0-devel.x86_64 4.0.0-14.fc27 will be installed
---> Package llvm-devel.x86_64 4.0.0-4.fc27 will be obsoleted
---> Package llvm4.0.x86_64 4.0.0-14.fc27 will be installed
---> Package llvm4.0-libs.x86_64 4.0.0-14.fc27 will be installed
---> Package llvm-libs.x86_64 4.0.0-4.fc27 will be obsoleted
---> Package llvm-devel.x86_64 4.0.0-4.fc27 will be upgraded
---> Package llvm-devel.x86_64 4.0.0-14.fc27 will be an upgrade
---> Package llvm.x86_64 4.0.0-4.fc27 will be upgraded
---> Package llvm.x86_64 4.0.0-14.fc27 will be an upgrade
--> Finished dependency resolution


It looks like llvm-devel.x86_64 4.0.0-4.fc27 is being both
obsoleted and upgraded, could that be the problem?

-Tom

[Vít Ondruch]

IMO, the latest package should be always non-versioned one and versioned
should be only the compat packages.

E.g. the llvm package is always the latest, shipping llvm 4.0 ATM and
llvm3.9 should be compat package, shipping the previous version. Once
new version is released, lets say llvm 5.0, the non-versioned llvm
should be migrated to that version and compat llvm4.0 should be introduced.

I tried to propose such guidelines a while ago [1] but failed, although
there was general consensus that this should be the way. So if I may
suggest, please don't introduced llvm4.0 yet.


Vít


[1] https://pagure.io/packaging-committee/issue/227


Dne 12.6.2017 v 23:01 Tom Stellard napsal(a):
>  Hi,
>
>  I'm working on moving the llvm-devel sub-package from the llvm package to
>  a new llvm4.0 package, however, when I upgrade from the llvm sub-package
>  to the llvm4.0 sub-package, I am getting file conflicts.
>
>  This can be reproduced on rawhide with these commands:
>
>  [root@746864b6a202 /]#  dnf install llvm-devel
>  [root@746864b6a202 /]#  dnf install 'dnf-command(copr)'
>  [root@746864b6a202 /]#  dnf copr enable tstellar/llvm-versioned
>  [root@746864b6a202 /]#  dnf install llvm-devel-4.0.0-13.fc27
>
>  Here is the error:
>
>  Error: Transaction check error:
>    file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64 conflicts with
> file from package llvm-devel-4.0.0-4.fc27.x86_64
>    file /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64 conflicts with
> file from package llvm-devel-4.0.0-4.fc27.x86_64
>
>  I don't understand how a package can conflict with on older version of
>  the same package.  Here are the spec files:
>
>  llvm-devel-4.0.0-13.fc27.x86_64:
> http://copr-dist-git.fedorainfracloud.org/cgit/tstellar/llvm-versioned/ll...
>  llvm-devel-4.0.0-4.fc27.x86_64:
> https://src.fedoraproject.org/cgit/rpms/llvm.git/tree/llvm.spec
>
>  Is this a bug in dnf/rpm or am I doing something wrong with the spec files?
>
>
>  -Tom
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Matthew Miller]

On Wed, Jun 14, 2017 at 12:22:53PM +0200, Vít Ondruch wrote:
>  IMO, the latest package should be always non-versioned one and
> versioned
>  should be only the compat packages.
>  E.g. the llvm package is always the latest, shipping llvm 4.0 ATM and
>  llvm3.9 should be compat package, shipping the previous version. Once
>  new version is released, lets say llvm 5.0, the non-versioned llvm
>  should be migrated to that version and compat llvm4.0 should be introduced. 
All other things aside, this is pragmatically easier, because creating
a new package4 or package5 triggers a new package review.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Jason L Tibbitts III]

> >>>> "MM" == Matthew Miller
> <mattdm(a)fedoraproject.org&gt; writes: 
MM> All other things aside, this is pragmatically easier, because
MM> creating a new package4 or package5 triggers a new package review.

That's not actually the case, though:

https://fedoraproject.org/wiki/Package_Review_Process

"Note that some new packages may be exempt from the review
process. Please see Packaging:ReviewGuidelines#Package_Review_Process
for a list of criteria. If an exemption is warranted, the contributor
can skip directly to step 8 of the process: filing a request in the
package database. But note that a bugzilla ticket will still be required
in order to complete that process; please use this bug for this purpose
and follow the instructions there. "

https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_...

Contributors and reviewers MUST follow the Package Review Process, with
the following exceptions:

* FPC grants an explicit exemption from the process, as indicated here.

* The package is being created so that multiple versions of the same
  package can coexist in the distribution. The package MUST be properly
  named according to the naming guidelines and MUST NOT conflict with
  all other versions of the same package. If these requirements are not
  met, an exemption is required as above.

 - J<

[Matthew Miller]

On Wed, Jun 14, 2017 at 02:05:38PM -0500, Jason L Tibbitts III wrote:
>  MM> All other things aside, this is pragmatically easier, because
>  MM> creating a new package4 or package5 triggers a new package review.
>  That's not actually the case, though:
>  https://fedoraproject.org/wiki/Package_Review_Process
>  "Note that some new packages may be exempt from the review
>  process. Please see Packaging:ReviewGuidelines#Package_Review_Process 
Oh! Mea culpa! Thanks for the correction!

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Jason L Tibbitts III]

> >>>> "MM" == Matthew Miller
> <mattdm(a)fedoraproject.org&gt; writes: 
MM> Thanks for the correction!

Sure.  It seems a lot of people miss this, though I tried to announce it
loudly back when it changed (in August).  I've been trying to cut down
on the bureaucracy, and a package that needs to add a
parallel-installable version is probably going to need to do so more
than once and constant reviews just get in the way.

Though I didn't try to push an exemption for package renames because
it's easy to get those wrong and tough to fix after it has gone wrong.
Plus, packages should really only be renamed rarely.

 - J<

[Matthew Miller]

On Wed, Jun 14, 2017 at 02:58:32PM -0500, Jason L Tibbitts III wrote:
>  Sure.  It seems a lot of people miss this, though I tried to announce
> it
>  loudly back when it changed (in August).  I've been trying to cut down
>  on the bureaucracy, and a package that needs to add a
>  parallel-installable version is probably going to need to do so more
>  than once and constant reviews just get in the way. 
Yeah, and thanks for that! I read all of your annoucements but
apparently didn't retain this one.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader