Dag Wieers wrote:
On Mon, 12 Oct 2009, Tom G. Christensen wrote:
Steve Huff wrote:
On Oct 12, 2009, at 2:46 AM, Tom G. Christensen wrote:
Ah yes, this is the real issue, the need to alert the user that a system
package is being replaced.
I feel strongly that deliberately breaking packages is the wrong way to deal
with the "alert the user that he's replacing a system package" problem.
It gives a bad user experience which will reflect badly on RPMforge and even
worse it encourages dangerous use of rpm (rpm --force).
If you want to give a special status to the perl packages, then put them in a
special repository instead of breaking the packages.
Right, seems logical. But then why are we adding this package, not because
it is newer, we add it because another package depends on this one. So the
logical next step is to also add the other package to this special
repository.
I'm not sure that's the case.
My goal is to solve the "alert the user that he's replacing a system
package" problem without keeping broken packages in the repo.
I don't want to split RPMforge in two.
To me that means buildroots that include all packages including those
that replace system packages from the special repo.
It's just that those that replace system packages get put aside to
intentionally break depedencies so as to alert a user that there is a
dependency on a package that will replace a system package.
But what then happens when you have tools that need this dependency, but
can also work with the original perl module. But one of them might break.
Suddenly you cannot use the special repository for application X, while
maybe application Y needs it.
And that's where the **** hits the fan.
Ahh yes.
I think what you're saying is that ie. perl-Sys-Syslog 0.16 breaks
something that works perfectly fine with 0.13 from perl CORE (and which
might even be part of RHEL) while perl-Log-Dispatch needs
perl-Sys-Syslog 0.16.
In that case wouldn't this problem be present in RPMforge right now?
I agree that the current situation is not a good one. I could once again
state that this is because of yum, since apt would not propose to update
it. But I also don't see a good fix for this.
Perhaps a yum plugin could modify this behaviour?
My preference would be to not replace upstream packages, and have a second
repository that does replace packages and carefully test also with both
repositories. But even if we do that, we will have to be very conservative
in what we would add. And make sure we don't add non-leaf (packages that
are a dependency of other packages).
Which would basicly mean we would drop this package altogether, together
with a dozen others (and all their dependencies).
Well it was not my intention to see RPMforge decimated when I brought
this up but I guess it would be a valid way to deal with the issue.
Depending on the scope of the problem perhaps it would be possible to
deal with it on a case by case basis instead of cutting away packages.
It is after all not something that seems to have had a high priority up
until now.
-tgc
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users
