[ https://jira.jboss.org/jira/browse/JOPR-64?page=com.atlassian.jira.plugin... ] Charles Crouch updated JOPR-64: ------------------------------- Description: Example of what I mean: 1) Create a content source pointing at a QA CSP feed. 2) Sync the content source and review the packages. Select a package and see the downloadUrl is pointing at the QA CSP infrastructure 3) Create a content source pointing at the Prod CSP feed. 4) Sync the content source and review the packages. Select a package and see the downloadUrl is still pointing at the QA CSP infrastructure. This means that even if you create a channel associated with the Prod content source and then subscribe a resource to this channel you will still end up trying to download a QA package when you try to apply a patch. The problem arises because we only use package name (e.g. JBoss AS 4.0.3.SP1_CP11) and package type (e.g. CP) to determine uniqueness of packages so both channels are providing information about what we think is the same package. I think the logical thing here is have each channel have its own unique packages, even though that means the rhq_package/rhq_package_version tables would need to change to take into account channel. This seems somewhat wasteful if you have a lot of identical packages across two content sources, but the current situation: What you have in your channel is determined by what old content sources you have deployed, doesn't seem tenable. was: Example of what I mean: 1) Create a content source pointing at a QA CSP feed. 2) Sync the content source and review the packages. Select a package and see the downloadUrl is pointing at the QA CSP infrastructure 3) Create a content source pointing at the Prod CSP feed. 4) Sync the content source and review the packages. Select a package and see the downloadUrl is still pointing at the QA CSP infrastructure. This means that even if you create a channel associated with the Prod content source and then subscribe a resource to this channel you will still end up trying to download a QA package when you try to apply a patch. I think the logical thing here is have each channel have its own unique packages, even though that means the rhq_package/rhq_package_version tables would need to change to take into account channel. This seems somewhat wasteful if you have a lot of identical packages across two content sources, but the current situation: What you have in your channel is determined by what old content sources you have deployed, doesn't seem tenable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JOPR-64?page=com.atlassian.jira.plugin... ] John Mazzitelli commented on JOPR-64: ------------------------------------- I misread the description - the issue is having the same package coming from two different content sources. This also, is by design. I specifically asked this question when the content subsystem was being implemented. The answer was that if a package has the same name and package type as another, it is considered to be the exact same package. If two content sources have the same name/type package but the package bits are different, that is very bad and should never occur (this was initially from the view point of a yum repo). Again, if this is to be changed, the entire subsystem needs to be reviewed since a refactoring of this magnitude would change ALOT! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira