On Sun, Aug 07, 2005 at 09:52:39AM +0200, Peter Boy wrote: > I appreciate your efforts very much and use atrpms for a long time > now. Didn't intended to hurt you (just to clarify) Thanks, and noone hurt me, I was claryfing things, too :) > and didn't want to reactivate the old discussion. Well, it's all in the archives, so it's a repetion of arguments, but it still comes up occasionally. Anyway, you're asking, so I'm giving back the canned answers (ATrpms should have an FAQ, I guess). > > There was nothing wrong with that, and there was nothing wrong > > with RH deciding to define the core and extras repos to not > > replace packages in each other. As there is nothing wrong with 3rd > > party repos replacing packages in core. > You are right, but it may be a problem, if a repo replaces packages > without the user beeing aware of it. And it is quite difficult to > use yours or dag's repo sometimes. If you do a yum update with all > repos activated, some packages will be updated by your repo or > dag's, weather those packages I use from your repo require it or > not! That is definitely a problem, I think. And such a replacement > may introduce problems for other software which are not visible in > terms of the rpm classifications. A package may introduce problems whether it formally replaces another one or not. Think of kernel modules packages (kmdls). If you want to play it safe, then disallowing replacements comes far after disallowing kernel modifications. Still noone seems to care about that. So I can only derive that these arguments are not really about stability of the system. I still think this is a political tool to distinguish some repos from others. Where there hasn't been a major repo not doing the replacement business in really critical packages. > A first step might be to differentiate your repo in atrpms/extra and > atrpm/addon, where the later contains packages which require a > replacement of core packages and those replacement packages. Why? Consider the next logical step, that any package depending on the replaced packages would need to be in the "replaments" repo just the same. And the replaced packages are mainly made for supporting *other packages*. So at the end you end up with only a couple of packages in the non-replacement repo, which by definition are the simple self-sustained packages. Not to mention that others request to split of "alternatives" repos, others "patent-encoumbered" ones and so one. So at the end, you will have "extras", "alternatives", "add-ons", "non-us" and this times three for the stability classes. The trouble isn't worth the benefits, even more so when the benefits are for countering witch-hunting. As soon as you manage to close the pseudo-arguments, new ones will pop up. And a final remark: All major repos are community efforts today, so anyone that wants to change something in one of the major repos, their policies, packaging styles, packages themselves, can join the respective developer/maintainer teams and try to perform the changes from inside. As anything in the OSS world, if you want to see something changed, get involved (isn't that why there are repos out ther in the first place ...). > > > If you wich to use the safe way, you should configure the other > > > repositories, but don't activate them by default (enabled=0 in the repo > > > file). If you look for a specific solftware package you may > > > > > > yum --enablerepro=[deactiveRepoName] search [myNeededSoftware] > > > > > > And if one of the alternative repos has it, you may install it from > > > there in the same way. > > > > which creates more bugs than it solves. The replaced packages in core > > are not for the sports of it. Sometimes they are because other > > packages require features in them that the core packages do not offer. > > > > Doing it by temporary enabling a repo (or even with > > priorities/weight settings like apt/smart do) leads to broken > > setups. > > > > If you don't trust a repo, don't use anything from it. It will make > > your life and the repo maintainers' lives far easier, as diagnosing > > these problems are a nightmare. > > See above, may resolve that. -- Axel.Thimm at ATrpms.net
Attachment:
pgpAxNcuRYAav.pgp
Description: PGP signature
