[Spacewalk-devel] Solution for NVREA issue?
jsherril at redhat.com
Wed Jun 25 11:35:04 EDT 2008
Jan Pazdziora wrote:
> On Wed, Jun 25, 2008 at 10:41:24AM -0400, Justin Sherrill wrote:
>> We could just use the md5sum to distinguish between them, but then
>> managing content becomes a nightmare. Where did this foo-0.1-1 come
> User bar pushed it into a channel xyz at YYYY-MM-DD HH24:MI:SS. Or,
> process get-repo synced it from URL http://.../... at YYYY-MM-DD
> Isn't the package mostly view in the context of a channel? So unless
> someone did something stupid, Fedora packages end up in Fedora
> channels (better yet, in channels the user named Fedora) and CentOS
> packages end up in CentOS channels.
Currently you can push content to the satellite without specifying a
channel, so a package may not always be added to a channel when pushing
it. Checking a log file somewhere is not really an acceptable solution
IMHO, and that's too much information to make easily digestible on a per
package basis. What if you have 100 different packages each with a
duplicate NVREA package and you don't know which is which? I'm not
saying for auditing sake, I'm just saying so you can look at a list of
packages and know where the heck they came from :}
Maybe this isn't a big deal for people, but i would think it would be.
We aren't just a content distributor (like epel), but also a content
management app. I'm afraid if we just track by gpg id, the management
part will become quite difficult.
What if we track by GPG id, but then have a way to associate the gpg id
>> what about this one? It would get very frustrating very fast.
> But it does not happen, normally. So the unique constraint does not
> really help to people who just use one parent to sync content. But it
> actively breaks things for people who try to do more complex things.
> The only thing that Spacewalk should enforce is one NVR per channel,
> since traditionally, NVR is the only (?) way the system uses to
> address a package it wants. But across channels?
>> I'm not really sure how common of a use case this would be (especially
>> considering you can't do it now). You could always bump the release or
>> version. The problem with having two packages of the same NVREA within
>> a channel tree, is how do you determine which one to install when the
>> client requests them? It needs to be deterministic, or else its just a
> By a channel.
>> guessing game.
> Right. Make it unique NVR per channel. Remove any restrictions across
>> You can still have two different packages within different channels, as
>> long as they are not within the same channel tree.
> What is a channel tree?
So if a system has 2 (or 3 or 4...) packages with the same NVREA, which
ones gets installed? Technically they don't have to be the same package
resigned. I'm guessing yum handles this currently (not sure which one
it chooses, possibly just the first one listed), but I know up2date
doesn't and all of dep solving will have to be modified to account for
More information about the Spacewalk-devel