On Sat, 21 Jul 2007, Michael Schwendt wrote:
On Sat, 21 Jul 2007 15:41:37 +0300 (EEST), Panu Matilainen wrote:
On Sat, 21 Jul 2007, Axel Thimm wrote:
On Sat, Jul 21, 2007 at 01:33:06PM +0300, Ville Skyttä wrote:
On Saturday 21 July 2007, Florian La Roche wrote:
On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skyttä wrote:
On Saturday 21 July 2007, Patrice Dumas wrote:
On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote:
Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is
Provides: foo
Conflicts: foo
really is a good idea. And can/should we use versioned Provides:
here?
Unless I am wrong, yum (rpm) won't care about versioned Provides:, and
replace foo+ with foo (I had such issues with libnet10/libnet).
No, that's a different bug probably. If one of the virtual provides
was a real entity then you trigger another rpm bug that was tagged a
feature (check bugzilla for concurrent python of some sound libs from
ccrma for details, I don't have the bz# handy): It automatically
introduces silent Obsoletes ...
FWIW, that particular "feature" is gone in rpm 4.4.2.1.
And packagers should still be very careful not to bring back "Provides:
foo = %version-%release" for compat-packages and alternatives. It would
only be a matter of time till the typical %{dist} mass-updates would
reintroduce problems for the old branches.
Yup. We can easily fix F7 and FC6 rpm but EPEL is another story
altogether.
- Panu -
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
