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. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
