[Fedora-packaging] Question about how libgcj-devel requires zlib

[Bruno Wolff III]

On Mon, Sep 22, 2008 at 15:47:51 -0400,
  seth vidal <skvidal at fedoraproject.org> wrote:
> On Mon, 2008-09-22 at 14:45 -0500, Bruno Wolff III wrote:
> 
> > Right now I am cla only and not in a good position to lead packaging
> > initiatives. (I want to eventually be a packager, but the code I have a
> > particular interest in packaging is written in java which I not that
> > familiar with and needs to have have copyrighted images scrubbed and
> > will still need to be looked at further because it is based on a boardgame.)
> > 
> > I don't think finding references to files and changing the providing packages
> > to explicitly provide them would be all that hard.
> 
> 
> Changing the pkgs AFTER the fact?

This would require new releases. Only the providing packages would need to
be changed to explicitly provide the capability corresponding to the file.
It's a LOT of grunt work, but not hard. This wouldn't break anything.
It doesn't even all need to be done at the same time. It would increase the
list of capabilities a couple of % (based on roughly 50000 capabilities in a
repo and on the order of 1000 packages that likely implicitly provide files as
capabilities). This wouldn't stop people from making new ones. To do that
you'd need to change yum/rpm to not work if they did. That would be a big
change that you'd want to do for a Fedora release.

However, I suspect that putting in all of those provides is something that
the project would want to undo later. (After thinking about about how
it would really be best to do things something other than file names might
end up being used.) So I doubt it is worth the work to do this. (At least
not before long term goals are set.)

If the (x86-32) stuff is relatively automatic it might be worth getting
a list of packages which would take advantage of this and get them
rebuilt. I don't know much about that feature, just waht Spot referred to and
that I saw a lot of capabilities with the string '(x86-32)' in them. Cleaning
up packages to make reference to the x86-32 capabilities might be harder.