On Oct 12, 2009, at 8:27 AM, Tom G. Christensen wrote:
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.
hm. that's certainly worth keeping in mind. so, just to make sure i'm understanding your suggestion correctly: you suggest that we set up an additional repo ([rpmforge-core-incompatible] or something), not enabled by default, and in that repo we would put... perl-Sys- Syslog-0.16? perl-Log-Dispatch-2.24 also?
i guess i'm not clear on why a yum error that says "i can't find this missing dependency" is preferable to a yum error that says "you're trying to install a package with a file conflict"; to my mind the current error makes it obvious what the problem is, but moving just perl-Sys-Syslog to a separate repository produces an error message that doesn't tell you whether you just need to enable an additional repo or whether the package is really not present at all.
plus, how to handle multiple architectures and distributions? a package bundled in core in el5 may not be in core in el3 and so forth, and so the idea of the same package version being in [rpmforge] for one distribution and [rpmforge-core-incompatible] for another distribution seems a bit odd.
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.
well, the current RPMforge practice is to not conflict/break system packages whenever possible, with relatively few exceptions. i suspect i'd be more excited about the prospect of maintaining multiple parallel repositories if this issue arose frequently, but the fact is it doesn't. personally, i'd far prefer a page on the wiki listing packages with known installation issues, and then people could just consult that page.
-steve --If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es/
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ users mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/users
