Steve Huff wrote:
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'd want to see just packages that upgrade system packages there.
Simply because it's logical and should be easy to maintain automatically.
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.
A package with a file conflict is inherently broken and can only be
installed by forcing the update (or using --exclude-docs in some cases).
Packages should be installable by the tools that users are used to, that
means yum or apt or even the "Add/Remove packages" GUI thing.
This becomes impossible when the package has a file conflict.
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.
RPMforge is not created equal for all versions of RHEL anyway ie. some
packages can only be built for el5 and not el4.
The logic of the split is straightforward and for users it would be
possible to determine at runtime in which repo a package can be expected
to live.
In the buildsystem it should be possible to maintain a list of system
packages for each distribution and make a decision on where to place
them automatically.
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.
Yes I'm aware of the current policy.
However this "one repo must fit all" approach could also prevent some
potential packages from being added.
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.
What is this fact based on?
personally, i'd far prefer a page on the wiki listing
packages with known installation issues, and then people could just
consult that page.
I'd prefer if such a page just had to say "for packages that override
system packages you need to additionally add
[rpmforge-core-incompatible]" and then give an example.
Oh and perhaps also "this is how you determine if what you're trying to
install is a system package".
This is just my personal opinion ofcourse and I do not exactly represent
the novice since I'm an experienced packager and Unix/Linux sysadm.
-tgc
_______________________________________________
users mailing list
[email protected]
http://lists.rpmforge.net/mailman/listinfo/users
