Re: Question about how libgcj-devel requires zlib

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 22 Sep 2008, Bruno Wolff III wrote:

On Mon, Sep 22, 2008 at 15:47:51 -0400,
 seth vidal <skvidal@xxxxxxxxxxxxxxxxx> 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.

The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff") automatically for all non-noarch packages (including subpackages), all that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x landed in rawhide already has them.

The main use-cases for this feature are:
a) -devel package dependencies on other -devel packages
b) BuildRequires
c) manual dependencies for plugins and such

Due to a) and b), almost everything in the distro could benefit from using them. For one, if all the relevant BuildRequires: are made to use ISA-provides instead of just the package name, we wouldn't need the monster exclude-lines in mock configs for multilib-capable systems to guarantee sane results.

	- Panu -

--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux