Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #16 from Mamoru Tasaka <mtas...@ioa.s.u-tokyo.ac.jp> 2009-01-12 13:27:00 EDT --- (In reply to comment #15) > (In reply to comment #13) > > i.e. if epiphany can be upgraded without gget-epiphany-extension > > is rebuilt, it is _already_ wrong. Not-rebuilt > > gget-epiphany-extension > > should prevent epiphany from being upgraded in such a case > > (theoretically). > > I disagree. It's better to temporarily loose a certain functionality than > prevent epiphany from being updated. People who are using rawhide are used to > thinks breaking from time to time, but still they are running rawhide because > they want to follow the latest development. > What if the epiphany update is part of a larger Gnome update? The older > epiphany might no longer work with the updated Gnome stuff and then we make > the > whole app useless instead of a single extension. "A larger Gnome update" in your sense had been already disturbed before many times (largely because some new gnome components won't build against new gnome libraries, gnome-desktop for example...). Other packages failing to rebuild have also prevented major packages in your sense from being upgraded. I can see no gain to loose dependency on this package for the reason you raised (and for this package you can simply remove this, while for gnome-desktop (for example) we actually have to wait until (almost) all package are rebuilt) > > Some idea: > > - Add "Conflicts: epiphany >= 2.23" > > "Conflicts: epiphany < 2.22" > > Congratulations, you have just made it conflict with _every_ epiphany release! > :) First of all: - Please don't use "congratulations" ":)" or "!" carelessly, please. While I don't know how commonly these words or emoticons are used in discussions like this bug report in your country, these words can be taken very differently than what you expect in other countries. Then: if epiphany has 2.22{,X} version, the epiphany won't conflict with these two. Note that this method is sometimes used when - A srpm creates 2 (or more) subpackages - The two packages don't depend on each other, and can be installed seperately or together - However if the versions of the two package differ, something nasty could occur > > - Ask epiphany maintainer to support "Provides: epiphany(abi) = 2.22", > > for example. > > And them make the extension "Requires: epiphany(abi) = 2.22"? What's the > advantage over "Requires: epiphany = 2.22"? It won't work for ephiphany minor release bump (i.e. 2.22.3, for example) For example ruby has "Provides: ruby(abi) = 1.8" while the current ruby version (on Fedora) is 1.8.6(.287) (and actually I think if epiphany changes the extension every time its major/middle version changes, epiphany should provide such information to rpm, like ruby, python or so actually do) > (In reply to comment #14) > > Also, as some packages already use %_libdir/epiphany/XXXX/extensions, > > making every package use this directory own this directory cannot be > > accepted and the owner of this directory must be unified. > > Why? We have a couple of these situations whenever one package does not > necessarily depend on the other. Duplicate ownership of a dir is bad, but > unowned dirs are even worse. But they all depend on epiphany. So I am asking you to ask epiphany maintainer first (as I did to vim maintainer). It is not desired that no one using that directory tries to argue with epiphany maintainer and gets satisfied with his/her "local" hack. KDE has kde-filesystem, font packages got to use fontpackages-filesystem and so on. Please contact with epiphany maintainer first. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
