I performed a clean minimal CentOS 5.2 install, fully updated the system, and then added the ATrpms repository. When I perform an update after adding the ATrpms repository, the package pm-utils is updated the the ATrpms repository. My understanding is there should not have been any updates as the stable version does not update system packages, right?
"The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if you only use the stable version. Packages in there do not overwrite system packages." [1]
If this is true, why did this package get updated?
Thanks, Kenneth
[1] http://wiki.centos.org/AdditionalResources/Repositories/
on 7-7-2008 12:45 PM Kenneth Burgener spake the following:
I performed a clean minimal CentOS 5.2 install, fully updated the system, and then added the ATrpms repository. When I perform an update after adding the ATrpms repository, the package pm-utils is updated the the ATrpms repository. My understanding is there should not have been any updates as the stable version does not update system packages, right?
"The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if you only use the stable version. Packages in there do not overwrite system packages." [1]
If this is true, why did this package get updated?
Thanks, Kenneth
[1] http://wiki.centos.org/AdditionalResources/Repositories/
You need to use the priorities plugin if you are going to use 3rd party repos. There is no other safe way about it.
On 7/7/2008 2:26 PM, Scott Silva wrote:
on 7-7-2008 12:45 PM Kenneth Burgener spake the following:
"The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if you only use the stable version. Packages in there do not overwrite system packages." [1]
[1] http://wiki.centos.org/AdditionalResources/Repositories/
You need to use the priorities plugin if you are going to use 3rd party repos. There is no other safe way about it.
I am not worried about what is did to my system, as this is a minor package. What I am more interested in is if this is a bug that needs to be reported?
Thanks, Kenneth
On Mon, Jul 07, 2008 at 04:20:30PM -0600, Kenneth Burgener wrote:
On 7/7/2008 2:26 PM, Scott Silva wrote:
on 7-7-2008 12:45 PM Kenneth Burgener spake the following:
"The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if you only use the stable version. Packages in there do not overwrite system packages." [1]
[1] http://wiki.centos.org/AdditionalResources/Repositories/
You need to use the priorities plugin if you are going to use 3rd party repos. There is no other safe way about it.
Using client side filtering is not recommended, it creates more bugs, than it can solve. The proper thing is to take care of it on the server side, where the package owners are supposed to know how to structure the repos.
I am not worried about what is did to my system, as this is a minor package. What I am more interested in is if this is a bug that needs to be reported?
Yes, as said the package owners are *supposed* to know how to structure the repo. ;)
But consider it reported, it has already been fixed (try yum update against the master, or wait for the mirrors to catch up). Thanks!
Axel Thimm wrote:
On Mon, Jul 07, 2008 at 04:20:30PM -0600, Kenneth Burgener wrote:
On 7/7/2008 2:26 PM, Scott Silva wrote:
on 7-7-2008 12:45 PM Kenneth Burgener spake the following:
"The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if you only use the stable version. Packages in there do not overwrite system packages." [1]
[1] http://wiki.centos.org/AdditionalResources/Repositories/
You need to use the priorities plugin if you are going to use 3rd party repos. There is no other safe way about it.
Using client side filtering is not recommended, it creates more bugs, than it can solve. The proper thing is to take care of it on the server side, where the package owners are supposed to know how to structure the repos.
Client filtering is not recommended by some people ... but highly recommended by others :-D
I would be one of the highly recommended votes
<snip>
On Tue, Jul 8, 2008 at 9:50 AM, Johnny Hughes jhughes@hughesjr.com wrote:
Axel Thimm wrote:
On Mon, Jul 07, 2008 at 04:20:30PM -0600, Kenneth Burgener wrote:
On 7/7/2008 2:26 PM, Scott Silva wrote:
on 7-7-2008 12:45 PM Kenneth Burgener spake the following:
"The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if you only use the stable version. Packages in there do not overwrite system packages." [1]
[1] http://wiki.centos.org/AdditionalResources/Repositories/
You need to use the priorities plugin if you are going to use 3rd party repos. There is no other safe way about it.
Using client side filtering is not recommended, it creates more bugs, than it can solve. The proper thing is to take care of it on the server side, where the package owners are supposed to know how to structure the repos.
Client filtering is not recommended by some people ... but highly recommended by others :-D
I would be one of the highly recommended votes
If you want to protect your box, use priorities, as Johnny and many others here recommend.. Nobody else is going to protect your box for you. You set the priorities and you protect it. To be polite, I believe the 4 line blurb above, about client side filtering is B.S. It is your box, it is your job to protect your box. Do not trust anyone else to protect your box, whether it is security related or related to repos for packages.
On Tue, Jul 08, 2008 at 12:17:58PM -0500, Lanny Marcus wrote:
On Tue, Jul 8, 2008 at 9:50 AM, Johnny Hughes jhughes@hughesjr.com wrote:
Axel Thimm wrote:
On Mon, Jul 07, 2008 at 04:20:30PM -0600, Kenneth Burgener wrote:
On 7/7/2008 2:26 PM, Scott Silva wrote:
on 7-7-2008 12:45 PM Kenneth Burgener spake the following:
"The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if you only use the stable version. Packages in there do not overwrite system packages." [1]
[1] http://wiki.centos.org/AdditionalResources/Repositories/
You need to use the priorities plugin if you are going to use 3rd party repos. There is no other safe way about it.
Using client side filtering is not recommended, it creates more bugs, than it can solve. The proper thing is to take care of it on the server side, where the package owners are supposed to know how to structure the repos.
Client filtering is not recommended by some people ... but highly recommended by others :-D
I would be one of the highly recommended votes
If you want to protect your box, use priorities, as Johnny and many others here recommend.. Nobody else is going to protect your box for you. You set the priorities and you protect it. To be polite, I believe the 4 line blurb above, about client side filtering is B.S. It is your box, it is your job to protect your box. Do not trust anyone else to protect your box, whether it is security related or related to repos for packages.
So, if it is indeed B.S. may I entitle you officer of resolving phantom bugs that emerge out of this? Imagine package foo requiring bar and both packages falling into the wrong client side filtering ... Or google for partial and/or selective filtering of repos.
At any rate this is moot for CentOS5 anyway as the repo is indeed (trying to) keep the base w/o any replacements, so you will never trigger these filtering features^Wbugs. But once you start using the full repo *and* filtering, all bug reports go Cc: to Lanny :)
On Tue, Jul 8, 2008 at 1:27 PM, Axel Thimm Axel.Thimm@atrpms.net wrote:
On Tue, Jul 08, 2008 at 12:17:58PM -0500, Lanny Marcus wrote:
On Tue, Jul 8, 2008 at 9:50 AM, Johnny Hughes jhughes@hughesjr.com
wrote:
Axel Thimm wrote:
On Mon, Jul 07, 2008 at 04:20:30PM -0600, Kenneth Burgener wrote:
On 7/7/2008 2:26 PM, Scott Silva wrote:
on 7-7-2008 12:45 PM Kenneth Burgener spake the following:
> "The CentOS 5/RHEL 5 repository from atrpms.net is safe to use, if
you
> only use the stable version. Packages in there do not overwrite
system
> packages." [1] > > [1] http://wiki.centos.org/AdditionalResources/Repositories/ > You need to use the priorities plugin if you are going to use 3rd
party
repos. There is no other safe way about it.
Using client side filtering is not recommended, it creates more bugs, than it can solve. The proper thing is to take care of it on the server side, where the package owners are supposed to know how to structure the repos.
Client filtering is not recommended by some people ... but highly recommended by others :-D
I would be one of the highly recommended votes
If you want to protect your box, use priorities, as Johnny and many others here recommend.. Nobody else is going to protect your box for you. You set the priorities and you protect it. To be polite, I believe the 4 line blurb above, about client side filtering is B.S. It is your box, it is your job to protect your box. Do not trust anyone else to protect your box, whether it is security related or related to repos for packages.
So, if it is indeed B.S. may I entitle you officer of resolving phantom bugs that emerge out of this? Imagine package foo requiring bar and both packages falling into the wrong client side filtering ... Or google for partial and/or selective filtering of repos.
At any rate this is moot for CentOS5 anyway as the repo is indeed (trying to) keep the base w/o any replacements, so you will never trigger these filtering features^Wbugs. But once you start using the full repo *and* filtering, all bug reports go Cc: to Lanny :) -- Axel.Thimm at ATrpms.net
Axel: Wasn't there a very long thread in this list, several months ago, about EPEL and the problems that would cause, since they do not want to include data that the other repositories include with their package information? There would be a lot of conflicts.
My belief is that priorities works well on CentOS (I see about 300 packages excluded, when I use yum to update on my desktops) and that not to use priorities is asking for trouble, if one has 3rd party repositories enabled. The goal is to keep the boxes up to date and not to get them clobbered, by something from a repository with a lower priority. That is very sound, IMHO. No need to CC me. Lanny
On Tue, Jul 08, 2008 at 03:14:18PM -0500, Lanny Marcus wrote:
Using client side filtering is not recommended, it creates more bugs, than it can solve. The proper thing is to take care of it on the server side, where the package owners are supposed to know how to structure the repos.
Axel: Wasn't there a very long thread in this list, several months ago, about EPEL and the problems that would cause, since they do not want to include data that the other repositories include with their package information? There would be a lot of conflicts.
I think the issue was not data, but lack of cooperation in the sense of checking against the other 3rd party repos on package conflicts.
My belief is that priorities works well on CentOS (I see about 300 packages excluded, when I use yum to update on my desktops)
That's probably already the problem. What 300 (!) package conlfict between which repos? I know that I'm trying to keep ATrpms 100% conflict free with CentOS5 for example (pm-utils was a bug that was now fixed)
and that not to use priorities is asking for trouble, if one has 3rd party repositories enabled. The goal is to keep the boxes up to date and not to get them clobbered, by something from a repository with a lower priority. That is very sound, IMHO. No need to CC me. Lanny
See the example for the different packaging of clamav where you might get a different set of clamav subpackages gathered from different repos due to priorities setups. You don't actually protect the system but you add to its destabilizaton, it's a false sense of security.
Bottom line is: The issue with package conflicts need to be fixed by humans, not filters - the first step is to allow users the choice of a pure add-on repo and a mixed one (like ATrpms does with abusing "stable" and "testing" repos). The next step is cooperating with other repos to avoid any clashes up to the point that these repos may get merged. That's what rpmrepo.org is about.
Johnny Hughes wrote:
Client filtering is not recommended by some people ... but highly recommended by others :-D
It's a good idea on important systems - but then you shouldn't open those machines to outside repositories anyway.
But if you don't do client-side filtering, you're helping the repositories to fix their problems and become cleaner. Everyone benefits in the long run.
There is no "one true answer to rule them all" in this case. Use client-side filtering on the machines that must not break under any circumstances. Relax the policy in the other cases. Use common sense.
On Tue, Jul 08, 2008 at 11:33:24AM -0700, Florin Andrei wrote:
Johnny Hughes wrote:
Client filtering is not recommended by some people ... but highly recommended by others :-D
It's a good idea on important systems - but then you shouldn't open those machines to outside repositories anyway.
But if you don't do client-side filtering, you're helping the repositories to fix their problems and become cleaner. Everyone benefits in the long run.
There is no "one true answer to rule them all" in this case. Use client-side filtering on the machines that must not break under any circumstances. Relax the policy in the other cases. Use common sense.
Just to present an example from Fedora: clamav within Fedora was and is considered rather cumbersome packaged and many users turn to 3rd party repos to get clamav installed.
If you place a filtering upon them, then some clamav subpackages will come from the 3rd party repo and some from Fedora base leading to a system that will possibly allow viruses to pass by. So actually the filtering will be destabilizing your setup instead of protecting them.
The true answer to this is cooperating/merged repos and we're targeting this on rpmrepo.org. Join up and be part of the solution :)
On Tue, Jul 8, 2008 at 12:42 PM, Axel Thimm Axel.Thimm@atrpms.net wrote:
On Tue, Jul 08, 2008 at 11:33:24AM -0700, Florin Andrei wrote:
Johnny Hughes wrote:
Client filtering is not recommended by some people ... but highly recommended by others :-D
It's a good idea on important systems - but then you shouldn't open those machines to outside repositories anyway.
But if you don't do client-side filtering, you're helping the repositories to fix their problems and become cleaner. Everyone benefits in the long run.
There is no "one true answer to rule them all" in this case. Use client-side filtering on the machines that must not break under any circumstances. Relax the policy in the other cases. Use common sense.
Just to present an example from Fedora: clamav within Fedora was and is considered rather cumbersome packaged and many users turn to 3rd party repos to get clamav installed.
If you place a filtering upon them, then some clamav subpackages will come from the 3rd party repo and some from Fedora base leading to a system that will possibly allow viruses to pass by. So actually the filtering will be destabilizing your setup instead of protecting them.
The true answer to this is cooperating/merged repos and we're targeting this on rpmrepo.org. Join up and be part of the solution :)
You might want to make some of the mailling lists public for people to join up on :).
The true answer to this is cooperating/merged repos and we're targeting this on rpmrepo.org. Join up and be part of the solution :)
You might want to make some of the mailling lists public for people to join up on :).
Argh! Was that always the case? I'll fix that.
On Tue, 2008-07-08 at 21:42 +0300, Axel Thimm wrote:
The true answer to this is cooperating/merged repos and we're targeting this on rpmrepo.org. Join up and be part of the solution :)
some years ago, the rpm hell dependencies was the worst nightmare for rpm based distros.
many people did at this ole times rpm --force like eating donuts.
some time ago, rpmforge try to do this atrpms try to do this after this epel try to do this rpmrepo can be really another thirdy repo again.
the comunity is the only one that can decide really.
-- Black Hand
Axel Thimm wrote:
Just to present an example from Fedora: clamav within Fedora was and is considered rather cumbersome packaged and many users turn to 3rd party repos to get clamav installed.
Actually, I stirred up a lot of muck not too long ago on a mailing list, exactly on this topic. The way they package clamav is less than useful for newbies and for those who just want to quickly enable a simple AV filter. It does help those who need a complex, sophisticated, multi-component setup. But those are exactly the people who don't need a lot of help, so why target the package towards them?
To become package maintainers - those lacking common sense need not apply.
On Tue, Jul 08, 2008 at 12:06:27PM -0700, Florin Andrei wrote:
Axel Thimm wrote:
Just to present an example from Fedora: clamav within Fedora was and is considered rather cumbersome packaged and many users turn to 3rd party repos to get clamav installed.
Actually, I stirred up a lot of muck not too long ago on a mailing list, exactly on this topic. The way they package clamav is less than useful for newbies and for those who just want to quickly enable a simple AV filter. It does help those who need a complex, sophisticated, multi-component setup. But those are exactly the people who don't need a lot of help, so why target the package towards them?
To become package maintainers - those lacking common sense need not apply.
clamav is indeed agitating. I generally exclude it from being auto-updated because it always needs major hand-holding each time it seems. :) Simple things like the configuration file just having wrong entries in it (missing boolean values)... ya just never know!
Getting off-topic now though I suppose. :)
Ray
on 7-8-2008 11:42 AM Axel Thimm spake the following:
On Tue, Jul 08, 2008 at 11:33:24AM -0700, Florin Andrei wrote:
Johnny Hughes wrote:
Client filtering is not recommended by some people ... but highly recommended by others :-D
It's a good idea on important systems - but then you shouldn't open those machines to outside repositories anyway.
But if you don't do client-side filtering, you're helping the repositories to fix their problems and become cleaner. Everyone benefits in the long run.
There is no "one true answer to rule them all" in this case. Use client-side filtering on the machines that must not break under any circumstances. Relax the policy in the other cases. Use common sense.
Just to present an example from Fedora: clamav within Fedora was and is considered rather cumbersome packaged and many users turn to 3rd party repos to get clamav installed.
If you place a filtering upon them, then some clamav subpackages will come from the 3rd party repo and some from Fedora base leading to a system that will possibly allow viruses to pass by. So actually the filtering will be destabilizing your setup instead of protecting them.
The true answer to this is cooperating/merged repos and we're targeting this on rpmrepo.org. Join up and be part of the solution :)
I think a big problem comes when a repo wants to build packageX, but it requires fancywidgetv2.1. But the base system only has fancywidgetv1.9. How would you get packagex without the possibility of breaking something unless fancywidgetv2.1 has backwards compatibility with fancywidgetv1.9?
On Tue, Jul 08, 2008 at 02:34:01PM -0700, Scott Silva wrote:
I think a big problem comes when a repo wants to build packageX, but it requires fancywidgetv2.1. But the base system only has fancywidgetv1.9. How would you get packagex without the possibility of breaking something unless fancywidgetv2.1 has backwards compatibility with fancywidgetv1.9?
I completely agree that this is one of the worse situation in multi-repo land today, let me detail on that:
First of all even if fancywidgetv2.1 were backwards compatible to fancywidgetv1.9 the promise of no replacemenet cannot be fulfilled, e.g. the task is to provide the two packages in a way that they don't remove/break fancywidgetv1.9 in any way.
There are two ways, you either package up fancywidgetv2.1 in a way that it coinstalls with other versions w/o breaking them. This works rather well with libraries that had an soname bump. ATrpms packages these as libfancywidget3-...-...rpm, where 3 is the SONAME.
The other way is to move both out of "stable" and into "testing". Or to the non-ATrpms speaking folks: Move it out of the repo that guarantees no replacements and into one that doesn't. That way the user needs to *consiously* choose to replace a package from base.
Note that in most cases the replacement packages are no worse than the others. In fact since they usually just turn on a feature or update the package they are probably even safer than using the less tested non-replacement packages. But since there are people that disagree with that opinion and beacuse Open Source is about choice we are trying hard to please everyone and push the choice to the user.
But the structuring needs to be done at the server side. How would a yum/smart/etc plugin know that packagex needs fancywidgetv2.1 over fancywidgetv1.9 unless there is a manual hard requirement in the package or a soname bump by happenstance?
And wrt manual versioned dependencies, who is really that disciplined to do that? I have a couple of packages in Fedora requiring say python
= 2.2 and I was repeatedly asked why I don't drop it -- the
dependencies are known to be there. Less dependencies make the specfile more readable.
So client side filtering needs a lot of love from packagers and a rethinking about minimal specfiles and if we do need human resources to do that, let's do it properly on the server side and keep packaging styles as they are.
On 7/7/2008 4:28 PM, Axel Thimm wrote:
On Mon, Jul 07, 2008 at 04:20:30PM -0600, Kenneth Burgener wrote:
I am not worried about what is did to my system, as this is a minor package. What I am more interested in is if this is a bug that needs to be reported?
Yes, as said the package owners are *supposed* to know how to structure the repo. ;)
But consider it reported, it has already been fixed (try yum update against the master, or wait for the mirrors to catch up). Thanks!
Axel,
Thank you for the quick turn around fixing this minor bug.
I see that the "pm-utils-0.99.3-6.el5.1cubbi_suspend2.i386.rpm" package has been moved from /stable/ to /testing/.
I just wanted to say that ATrpms is an awesome and very well maintained repository which I use for all my MythTV needs. I rarely if ever run into problems with this repository.
Thank you again. Kenneth
If this is true, why did this package get updated?
Can't answer that, but do you use yum-priorities? I was actually just looking at ATRPMS and about to see if it had what I needed for a new install. It would be good to know if that problem happened with the repo protection in place...
jlc
on 7-7-2008 2:28 PM Joseph L. Casale spake the following:
If this is true, why did this package get updated?
Can't answer that, but do you use yum-priorities? I was actually just looking at ATRPMS and about to see if it had what I needed for a new install. It would be good to know if that problem happened with the repo protection in place...
jlc
I have atrpms on a few servers, but usually leave it disabled, then if I need something I "yum --enablerepo=atrpms install ....
You can also turn it on occasionally with update and just say no if it looks like it wants to replace any system modules.
-
Axel Thimm -
BlackHand -
Florin Andrei -
Johnny Hughes -
Joseph L. Casale -
Kenneth Burgener -
Lanny Marcus -
Ray Van Dolson -
Scott Silva -
Stephen John Smoogen