On Tue, Aug 09, 2005 at 05:19:22PM -0500, Les Mikesell wrote: > On Tue, 2005-08-09 at 15:59, Axel Thimm wrote: > > No, certainly not everything. And if you relocate all to /usr/local > > what benefits will you have??? > > The same benefits you have from compiling from source to /usr/local. > You don't break anything already existing in the distribution and > you don't lose the ability to get updates to anything from the > distribution. We are talking about packages bleding in into the distribution, not self-compiled sources under /usr/local, right? And about such packages that other are going to depend on. > > You would either have /usr/local before /usr, so it's the same like > > unistalling the old package, or after, which is the same like not > > installing the new one ... > > Yes, Packages are not meant to be turned on and off by the structure of your PATH variable, the above was to clarify that this is not sensical, not to confirm the situation ... > as a side effect you could still run the stock package if you > wanted, but that is probably less useful than the fact that you > would not have introduced RPM dependency conflicts that keep you > from doing updates. Trading a hypothetical "rpm dependency conflict" with a certainly broken setup? > > > > For having users decide their experimentation level themselves, some > > > > repos have stability split repos, which is a far more useful thing to > > > > do. > > > > > > It doesn't make much sense to me to call a repo stable if it is > > > still allowed to contain rpms that conflict with the distribution's > > > own. > > > > Not if you are defining "updates"/"enhances" equal to "conflicts". In > > this manner even updates-released is not stable, as it "conflicts" > > core packages ... :) > > By 'conflicts', I mean has the potential to introduce dependencies > on different versions of the same-named packages. As long as everything > is compiled in the same environment that won't happen. If a 3rd party > repo replaces a stock library with a different modification It is the repo's resposibility to ensure that any vendor package depending on the replaced package still has its dependenices proper. Yes, for some libraries that bump their library major version this means that the repo has to provide compatibility packages. Now you know what the dozen or so compat-* packages at ATrpms are doing ... > and has a package that depends on it, what is supposed to happen > when the distribution releases a needed update to that library and > package updates that depend on it? Almost by definition a distribution does not update non leaf-packages that would break APIs/ABIs. Same goes for the 3rd parties (where the APIs/ABIs are vendor-given). > > Almost all my setups are Fedora Core/RHEL full installs with ATrpms > > upon that (and more). Nothing _conflicts_, and it *is* _stable_. > > And no replaced stock RPMs? I did write "with ATrpms upon that", so what are you asking about? > Can you be sure that it will still be stable regardless of what is > pulled from the distribution's updates? The above is with updates ... Please let's get down to earth and talk about facts and not academical hypothesis. 3rd party repos have not popped up only yesterday, and do a good job in enhacing the base distribution, be it by sometimes replacing vendor packages or not. This works for a couple of years now, and while no software bit is bug-free (inlcuding both the vendor's and the 3rd parties'), the core replaced packages have been less of an issue (probably because they partly have been replaced to fix bugs ...) Please, let's kill this thread now, it is both getting off-topic, repeating canned arguments found in several archives, and is getting boring. If you still don't agree, the let's all enjoy our opinions of our own. -- Axel.Thimm at ATrpms.net
Attachment:
pgpX9JEaIy3VB.pgp
Description: PGP signature
