Steve Huff wrote:
On Oct 12, 2009, at 2:46 AM, Tom G. Christensen wrote:
This is still just a workaround for an issue that RPMforge should
have dealt with instead of putting this burden on the user.
eh? how would you suggest that RPMforge address this particular
issue? i can see essentially three options:
From a purely technical standpoint there are several possible solutions
but perhaps that is not the real issue...
1) don't package Log::Dispatch 2.24 (and too bad for anybody who needs
it)
This is certainly a valid option though not the one I would prefer.
2) package Sys::Syslog 0.16 without a man page, or with man page in
some nonstandard location (thus "hiding" the fact that we're replacing
a system package)
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.
I would personally prefer to give this special status to any packages
that upgrade system packages (perhaps with some exceptions but it should
be the general rule).
However I'd be comfortable with a middle ground between the ATrpms
(aggressive) and EPEL (conservative) way of doing things.
3) package Log::Dispatch 2.24 with incorrect dependency information
(which means it installs, but potentially doesn't work)
Ofcourse not.
i don't particularly like any of those options better than the current
situation. can you suggest another fix?
I hope I've answered your question above.
-tgc
_______________________________________________
users mailing list
users@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users
