I've been trying out the protectbase plugin for yum, and haven't yet determined the best way to selectively update a package. E.g. I'd like to mark the base repo as protected, but get the latest firefox from the centosplus repo.
What's the correct incantation for this?
On Thu June 29 2006 16:20, Bart Schaefer wrote:
I've been trying out the protectbase plugin for yum, and haven't yet determined the best way to selectively update a package. E.g. I'd like to mark the base repo as protected, but get the latest firefox from the centosplus repo.
What's the correct incantation for this?
Goto your /etc/yum.repos.d and edit CentOS-Base.repo and do the following;
under [base] add exclude=firefox
Under [centosplus] add includepkgs=firefox
On Fri, 2006-06-30 at 19:59 -0400, Robert Spangler wrote:
On Thu June 29 2006 16:20, Bart Schaefer wrote:
I've been trying out the protectbase plugin for yum, and haven't yet determined the best way to selectively update a package. E.g. I'd like to mark the base repo as protected, but get the latest firefox from the centosplus repo.
What's the correct incantation for this?
Goto your /etc/yum.repos.d and edit CentOS-Base.repo and do the following;
under [base] add exclude=firefox
Under [centosplus] add includepkgs=firefox
But - this will effectively exclude all other centosplus packages. May/may-not be what was wanted. I've also played with protectbase and found it difficult to find the right combination of protect=0/1 and include/exclude to get the desired behavior to allow some packages from add-on repos. Eventually ended up with protect=1 for all the repos I wanted to use which kind of defeats the purpose.
Phil
On Sat, 2006-07-01 at 09:42 -0400, Phil Schaffner wrote:
On Fri, 2006-06-30 at 19:59 -0400, Robert Spangler wrote:
On Thu June 29 2006 16:20, Bart Schaefer wrote:
I've been trying out the protectbase plugin for yum, and haven't yet determined the best way to selectively update a package. E.g. I'd like to mark the base repo as protected, but get the latest firefox from the centosplus repo.
What's the correct incantation for this?
Goto your /etc/yum.repos.d and edit CentOS-Base.repo and do the following;
under [base] add exclude=firefox
Under [centosplus] add includepkgs=firefox
But - this will effectively exclude all other centosplus packages. May/may-not be what was wanted. I've also played with protectbase and found it difficult to find the right combination of protect=0/1 and include/exclude to get the desired behavior to allow some packages from add-on repos. Eventually ended up with protect=1 for all the repos I wanted to use which kind of defeats the purpose.
Phil
When you use protectbase ... you are saying this:
For all repos where protect=1, use normal update rules ... but, for all repos where protect=0 do not update any packages in a protect=1 repo.
SO ....
If you every want centosplus to replace anything in base then they would both have to be in either protect=1 (or both repos would need to be in protect=0).
In that case, you would still need to use exclude and includepkgs to manage which other packages from centosplus would be updated.
The purpose of the protectbase plugin is to protect a repo (like base) ... from a repo (like atpms).
It isn't defeating the purpose ... That is how it is designed :)
On 6/30/06, Robert Spangler lazydog@zoominternet.net wrote:
under [base] add exclude=firefox
I was afraid this was the answer. The trouble here is that, come 4.4, the firefox package in the base is going to be newer than the one in centosplus. I don't want to exclude firefox from the base, I want the most recent one from either of the base or plus repos, without having to get everything else from the plus repo.
This exclude is what I've used for now, but I think it's sub-optimal.
Under [centosplus] add includepkgs=firefox
This doesn't appear to be necessary in combination with the exclude and protect=1 on base. Hmm, what would happen if I left out the exclude for base but used the include for plus?
On 7/1/06, Bart Schaefer barton.schaefer@gmail.com wrote:
Hmm, what would happen if I left out the exclude for base but used the include for plus?
I tried this with the kernel* packages and it doesn't do what I hoped, unless I also turn off protect on base, which sort of defeats the purpose. Oh, well.
Related question: How does one get a list of the contents of a repo so as to maintain a correct includepkgs line, while still having the includepkgs line present? E.g. suppose some new package is added to centosplus that I might want to use to update a base package. If I have an includepkgs line for centosplus, "yum check-update" will never show me that a new package is there, because it will ignore everything except what's already in the includepkgs line.
On Sat, 2006-07-01 at 09:14 -0700, Bart Schaefer wrote:
On 7/1/06, Bart Schaefer barton.schaefer@gmail.com wrote:
Hmm, what would happen if I left out the exclude for base but used the include for plus?
I tried this with the kernel* packages and it doesn't do what I hoped, unless I also turn off protect on base, which sort of defeats the purpose. Oh, well.
Related question: How does one get a list of the contents of a repo so as to maintain a correct includepkgs line, while still having the includepkgs line present? E.g. suppose some new package is added to centosplus that I might want to use to update a base package. If I have an includepkgs line for centosplus, "yum check-update" will never show me that a new package is there, because it will ignore everything except what's already in the includepkgs line.
How I do it is with a separate config file (not named .repo) that you can pass in via the command line ...
yum -c /path/to/yum.check.conf
On Fri, 30 Jun 2006, Robert Spangler wrote:
On Thu June 29 2006 16:20, Bart Schaefer wrote:
I've been trying out the protectbase plugin for yum, and haven't yet determined the best way to selectively update a package. E.g. I'd like to mark the base repo as protected, but get the latest firefox from the centosplus repo.
What's the correct incantation for this?
Goto your /etc/yum.repos.d and edit CentOS-Base.repo and do the following;
under [base] add exclude=firefox
Under [centosplus] add includepkgs=firefox
In fact the protectbase plugin should understand that if you force a package out of base, that this is the desired behaviour and pull new packages from the repository it came from.
This behaviour would allow people to override protectbase and make it permanent. Yum in that case needs to display what it is doing so there's no chance of misinterpreting the behaviour.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Sun, 2006-07-02 at 14:12 +0200, Dag Wieers wrote:
On Fri, 30 Jun 2006, Robert Spangler wrote:
On Thu June 29 2006 16:20, Bart Schaefer wrote:
I've been trying out the protectbase plugin for yum, and haven't yet determined the best way to selectively update a package. E.g. I'd like to mark the base repo as protected, but get the latest firefox from the centosplus repo.
What's the correct incantation for this?
Goto your /etc/yum.repos.d and edit CentOS-Base.repo and do the following;
under [base] add exclude=firefox
Under [centosplus] add includepkgs=firefox
In fact the protectbase plugin should understand that if you force a package out of base, that this is the desired behaviour and pull new packages from the repository it came from.
This behaviour would allow people to override protectbase and make it permanent. Yum in that case needs to display what it is doing so there's no chance of misinterpreting the behaviour.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
I agree that would be desirable behavior ... now, how to program that, no idea :)
If there is someone out there who is smart enough to make that happen, please do :)
Protect base (as written) is just for protecting a group of repos (in the protect=1 category) from another group of repos (in the protect=0 category).
Per repo excludes and/or includepkgs can be used to make things work though ...
That may be hard to do ... but that is how yum works.
There is another plugin we are testing (called yum-plugin-priorites), and there seems to be some issue with the "obsoletes" option now. This one allows you to assign a priority to repos from 1-100 ... even with this one though, you would have to exclude packages from higher priority repos to get them be drawn from other repos.
Per repo excludes and/or includepkgs can be used to make things work though ...
That may be hard to do ... but that is how yum works.
I haven't read much on the topic. However, here's a suggestion.
Group repos into groups. When doing yum list, list the most current packages from _each_ repogroup.
Ie, current behaviour:
[maze@tcs ~]$ yum list php Available Packages php.i386 4.3.9-3.12 updates
[maze@tcs ~]$ yum --enablerepo=centosplus list php Available Packages php.i386 5.0.4-5.centos4 centosplus
desired behaviour (assuming centosplus and updates are in different repo groups):
Available Packages php.i386 4.3.9-3.12 updates php.i386 5.0.4-5.centos4 centosplus
This means you can choose which repo to install the given package from. Possibly yum install php would now ask you to select a repogroup (ie. The package php is available from the following repogroups: 1. centos base/addons/extras/updates 2. centosplus Please select the repogroup to use for this package:)
Example groups: - centos: base/addons/extras/updates - centosplus - dag/dries - etc...
Next, keep a database (maybe just a text file) from which repo (or repogroup) each package was installed, and consider only packages from the same repogroup to be valid upgrade paths. And refuse to install stuff that would require a cross-repogroup upgrade (or make a big fat warning dialog y/n default no box).
Comments? MaZe
On Sun, 2006-07-02 at 15:55 +0200, Maciej Żenczykowski wrote:
<snip>
Next, keep a database (maybe just a text file) from which repo (or repogroup) each package was installed, and consider only packages from the same repogroup to be valid upgrade paths. And refuse to install stuff that would require a cross-repogroup upgrade (or make a big fat warning dialog y/n default no box).
Regardless of any other restrictions/enablements, the "data base" is key. If a data base can tell from whence the original package (OP? ;-) came, it can be used to ensure that updates/upgrades only come from there... unless we really examine the need and we then see that the use should be able to a) override, b) permanently change, ...
Regardless, A DB will set us free.
Comments? MaZe
<snip sig>
On Mon, 3 Jul 2006, William L. Maltby wrote:
On Sun, 2006-07-02 at 15:55 +0200, Maciej ÿÿenczykowski wrote:
<snip>
Next, keep a database (maybe just a text file) from which repo (or repogroup) each package was installed, and consider only packages from the same repogroup to be valid upgrade paths. And refuse to install stuff that would require a cross-repogroup upgrade (or make a big fat warning dialog y/n default no box).
Regardless of any other restrictions/enablements, the "data base" is key. If a data base can tell from whence the original package (OP? ;-) came, it can be used to ensure that updates/upgrades only come from there... unless we really examine the need and we then see that the use should be able to a) override, b) permanently change, ...
Regardless, A DB will set us free.
The DB is called rpmdb. The repository (or better source) of a package could be the key(s)/signature(s).
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, 2006-07-05 at 01:27 +0200, Dag Wieers wrote:
On Mon, 3 Jul 2006, William L. Maltby wrote:
On Sun, 2006-07-02 at 15:55 +0200, Maciej ÿÿenczykowski wrote:
<snip><snip>
Regardless, A DB will set us free.
The DB is called rpmdb. The repository (or better source) of a package could be the key(s)/signature(s).
I've been reminded that this is OT for this list, so I say only see the other posts.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
<snip sig stuff>
On Sun, 2006-07-02 at 08:33 -0500, Johnny Hughes wrote:
On Sun, 2006-07-02 at 14:12 +0200, Dag Wieers wrote:
On Fri, 30 Jun 2006, Robert Spangler wrote:
On Thu June 29 2006 16:20, Bart Schaefer wrote:
<snip>
What's the correct incantation for this?
Goto your /etc/yum.repos.d and edit CentOS-Base.repo and do the following;
under [base] add exclude=firefox
Under [centosplus] add includepkgs=firefox
In fact the protectbase plugin should understand that if you force a package out of base, that this is the desired behaviour and pull new packages from the repository it came from.
This behaviour would allow people to override protectbase and make it permanent. Yum in that case needs to display what it is doing so there's no chance of misinterpreting the behaviour.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
I agree that would be desirable behavior ... now, how to program that, no idea :)
If there is someone out there who is smart enough to make that happen, please do :)
I don't see it happening in the current context. AFAICT, yum and/or rpm "forget" where an installed package came from. Correct? If so, consistent update behavior depends on 1) packages that didn't exist in repo A and were obtained from repo B never appear in a later version in repo A, 2) the naming conventions used to distinguish packages among repos (.rf, .plus, ...) prevent a "match" process unless the "base name" and variations to it are "well known" to yum, and 3) extremely vigilant users ready to sling/retract "includepkgs" and "exclude" statements at a moment's notice.
Sort of defeats the whole purpose of Yum. It may be that the number of and relationship between repos far exceeds Yum's basic design intent. Or maybe it's the style of usage?
What this comes down to, IMO, is that the usage environment and scenario has changed (? or was never a match) sufficiently that an adequate specification of the "new" environment and requirements is needed. What I have seen here (and I look nowhere else) is a piecemeal approach as "issues" are discovered. I understand that this may be the "favored" method in the FSS world, but it remains woefully inefficient and leads to what we've been seeing. It would seem to require coordination and cooperation among repo maintainers, yum developers and "users" (in my mind, mostly CentOS developers/packagers and some of the more aggressive users).
Since the "base data" is extremely "fluid" (my kindest terminology), meaning that a later version of any package can appear in any repo at any time and need to be included/excluded by any user, or not ...
Only a re-visitation of the design considering all the current factors, desired use schema, .... can result in a "satisfactory" long-term solution.
OTOH, things can continue as they are as only a select few individuals are caused any inconvenience (ignoring the folks who field the questions, those who wonder "why don't they search the archives before asking", ...).
<snip>
MHO
On 7/3/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
I don't see it happening in the current context. AFAICT, yum and/or rpm "forget" where an installed package came from. Correct?
Doesn't matter. It would be sufficient if I could tell the [base] repo
protect=1 unprotect=firefox*
I don't care if firefox always comes from the *same* repository, I want it to always be *the most recent* RPM from any/all of the enabled repositories. I don't want to exclude it from the base repo list, I only want to exclude it from "protection".
On Mon, 2006-07-03 at 12:26 -0700, Bart Schaefer wrote:
On 7/3/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
I don't see it happening in the current context. AFAICT, yum and/or rpm "forget" where an installed package came from. Correct?
Doesn't matter. It would be sufficient if I could tell the [base] repo
protect=1 unprotect=firefox*
I don't care if firefox always comes from the *same* repository, I want it to always be *the most recent* RPM from any/all of the enabled repositories. I don't want to exclude it from the base repo list, I only want to exclude it from "protection".
I like that thought. It solves the current issue and a couple others too.
Now if we can be sure that Yum understands that .rf, .plus, ... are all the same packages, we're home free. But ... are they the same packages? This may be a dumb question, but can we be sure firefox from one repo is compatible with what a user runs? Kernel features differences, etc. For firefox, maybe the answer is yes. Does that apply generally to other packages too? Is the "unprotect" solution certain to be "generally applicable"? OTOH, that is a user administration problem, isn't it?
<snip sig stuff>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jul 03, 2006 at 03:39:55PM -0400, William L. Maltby wrote:
Now if we can be sure that Yum understands that .rf, .plus, ... are all the same packages, we're home free. But ... are they the same packages? This may be a dumb question, but can we be sure firefox from one repo is compatible with what a user runs? Kernel features differences, etc. For firefox, maybe the answer is yes. Does that apply generally to other packages too? Is the "unprotect" solution certain to be "generally applicable"? OTOH, that is a user administration problem, isn't it?
Actually, that is a minor issue. RPM itself has the final vote on who is the newest package. So YUM really should not worry about it. At least, I hope YUM uses rpmVersionCompare.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Mon, 2006-07-03 at 16:47 -0300, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jul 03, 2006 at 03:39:55PM -0400, William L. Maltby wrote:
Now if we can be sure that Yum understands that .rf, .plus, ... are all the same packages, we're home free. But ... are they the same packages? This may be a dumb question, but can we be sure firefox from one repo is compatible with what a user runs? Kernel features differences, etc. For firefox, maybe the answer is yes. Does that apply generally to other packages too? Is the "unprotect" solution certain to be "generally applicable"? OTOH, that is a user administration problem, isn't it?
Actually, that is a minor issue. RPM itself has the final vote on who is the newest package. So YUM really should not worry about it. At least, I hope YUM uses rpmVersionCompare.
That leads me to another thought. Have we been seeing issues in which Yum has become a counter-productive solution? As with any tool, Yum was designed with a certain set of needs to be addressed and a certain set of condition in which it expected to operate.
Are some of the answers given for "how to do it with Yum" really a disservice? Maybe some answers should be "Forget Yum for your situation, use RPM directly"?
I only ask because we have all seen how easily we fall into the process of fitting a square peg into a round hole when all we needed to do was grab a round peg.
Rodrigo Barbosa
<snip sig stuff>
On Mon, 2006-07-03 at 16:47 -0300, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jul 03, 2006 at 03:39:55PM -0400, William L. Maltby wrote:
Now if we can be sure that Yum understands that .rf, .plus, ... are all the same packages, we're home free. But ... are they the same packages? This may be a dumb question, but can we be sure firefox from one repo is compatible with what a user runs? Kernel features differences, etc. For firefox, maybe the answer is yes. Does that apply generally to other packages too? Is the "unprotect" solution certain to be "generally applicable"? OTOH, that is a user administration problem, isn't it?
Actually, that is a minor issue. RPM itself has the final vote on who is the newest package. So YUM really should not worry about it. At least, I hope YUM uses rpmVersionCompare.
You just provided the "connector" in my thinking. Another poster mentions DB, RPM has a DB, RPM's DB retains the external name, the external name contains ".rf", ".plus", ... Voila! Yum can, if it chooses, use the RPM DB, tell which repo provided the currently installed package instance, combine that with includepkgs/exclude, (un)protect, .... Another DB (yum.conf, repos, ... or a DBMS) can provide some additional "rules".
Rodrigo Barbosa
<snip sig stuff>
On Mon, Jul 03, 2006 at 04:18:44PM -0400, William L. Maltby enlightened us:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jul 03, 2006 at 03:39:55PM -0400, William L. Maltby wrote:
Now if we can be sure that Yum understands that .rf, .plus, ... are all the same packages, we're home free. But ... are they the same packages? This may be a dumb question, but can we be sure firefox from one repo is compatible with what a user runs? Kernel features differences, etc. For firefox, maybe the answer is yes. Does that apply generally to other packages too? Is the "unprotect" solution certain to be "generally applicable"? OTOH, that is a user administration problem, isn't it?
Actually, that is a minor issue. RPM itself has the final vote on who is the newest package. So YUM really should not worry about it. At least, I hope YUM uses rpmVersionCompare.
You just provided the "connector" in my thinking. Another poster mentions DB, RPM has a DB, RPM's DB retains the external name, the external name contains ".rf", ".plus", ... Voila! Yum can, if it chooses, use the RPM DB, tell which repo provided the currently installed package instance, combine that with includepkgs/exclude, (un)protect, .... Another DB (yum.conf, repos, ... or a DBMS) can provide some additional "rules".
You need to make sure you understand that the "name" does not contain .rf, .plus or otherwise. That is (generally) part of the Release String. RPMs are named in a Name-Version-Release.Arch pattern.
This has been discussed on the yum mailing list previously, and it is difficult (at best) to track what repository an RPM came from, especially when RPMs are installed by hand, repositories are removed, etc. The RPM database does not allow for this information in its current implementation.
In order to implement what you suggest above goes beyond yum into RPM-land. Either way, this probably isn't the right mailing list for this discussion.
Matt
On Mon, 2006-07-03 at 16:31 -0400, Matt Hyclak wrote:
On Mon, Jul 03, 2006 at 04:18:44PM -0400, William L. Maltby enlightened us:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Jul 03, 2006 at 03:39:55PM -0400, William L. Maltby wrote:
<snip>
You need to make sure you understand that the "name" does not contain .rf, .plus or otherwise. That is (generally) part of the Release String. RPMs are named in a Name-Version-Release.Arch pattern.
Knew that it was not an official field. Presummed some parsing would be needed. Just part of the jon if one chooses to go that way.
This has been discussed on the yum mailing list previously, and it is difficult (at best) to track what repository an RPM came from, especially when RPMs are installed by hand, repositories are removed, etc. The RPM database does not allow for this information in its current implementation.
In order to implement what you suggest above goes beyond yum into RPM-land. Either way, this probably isn't the right mailing list for this discussion.
Yep. I always get seduced by all the apparently OT threads we see without complaint. So I just jump right in with my own OT thread.
Matt
On 7/3/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
This may be a dumb question, but can we be sure firefox from one repo is compatible with what a user runs?
That's already a problem, independent of the protectbase plugin. One must already be careful of what repositories one enables, outside of the CentOS set. Using includepkgs or exclude to restrict partly compatible or incompatible repositories is both appropriate and satisfactory.
On Mon, 2006-07-03 at 12:57 -0700, Bart Schaefer wrote:
On 7/3/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
This may be a dumb question, but can we be sure firefox from one repo is compatible with what a user runs?
That's already a problem, independent of the protectbase plugin. One must already be careful of what repositories one enables, outside of the CentOS set. Using includepkgs or exclude to restrict partly compatible or incompatible repositories is both appropriate and satisfactory.
Until one has such a large number of them that it becomes cumbersome. A standard response "if they have that many ...." doesn't cut it either, as this whole environ is about freedom of choice.
<snip sig stuff>
-
Bart Schaefer -
Dag Wieers -
Johnny Hughes -
Maciej Żenczykowski -
Matt Hyclak -
Phil Schaffner -
Robert Spangler -
Rodrigo Barbosa -
William L. Maltby