Bug 346351

And I think we should move it to rhn-tools channel so client can use it on any
machine. Now it is available only on satellite channel. But API script can be
run on any machine.

Clifford Perry wrote:
> So negatives:
> - we ship it, we support it - does giving wider exposure to customers 
> hinder us? (doubt full - package is well established)
> - Customers may use it for non RHN API related perl coding, hit issues 
> we did not previously know off
> - Security holes in package? (need to check upstream)
> 
> Positives:
> - Non-Satellite customers using Hosted API will now have the perl code 
> freely available to them in tools channel.
> - convenience for customers who wish to use perl based client API 
> scripts for Hosted and Satellite, not to have to dig for the package.
> - why not? (see negatives, are we missing a negative)

I downloaded new version and given security patch. Modified SPEC,
Commited changes to trunk (rev. 133535).

I done two additonal things
- move to apache2 modules
- apart from perl-Frontier-RPC, which contain Daemon, XMLRPC ..., I created
package perl-Frontier-RPC-Client, which will go to tools channel.
rev. 133630

perl-Frontier-RPC-Client did not landed in either rhn-tools nor satellite channel. 

Mirek - need help to ensure the package hits the channels?

For new package to get into a channel we have to promote the package into the
right collections. 

Release Engineering then picks it up from there... they will want for Satellite
- to have the package added into the cvs/rhn/satellite/MANIFEST file. 

for Tools - I do not know, as I have not done this before. I am adding Brandon
and Prad to CC, they should either be able to point to the right place for
tools, or do it for us (letting know what file they touched)... 
 
http://svn.rhndev.redhat.com/viewcvs/trunk/docs/rel_eng/release/how-to-do-a-push.txt

shows that we use the scripts:
~/svn/rhn-svn/trunk/eng/stale-scripts/channels/populate-rhn-tools*.sh 

to do the population of tools content. 

So, looks like we statically list the package names we wish to push, for things
such as rhn-virtualization-common - so yeah.. lets flag prad/brandon to do this
change for us. 

Cliff. 

I added package to manifest:
/cvs/rhn/rhn/satellite/MANIFEST-4AS,v  <--  MANIFEST-4AS
new revision: 1.73; previous revision: 1.72

From release team:
A general feeling was to try and see if we could get this into the RHEL release,
either Extras channel or main distro along with the other perl modules.

Basic argument, nearly all our tools expose and use XML-RPC for API, bugzilla,
RHN, Issue Tracker, and more no doubt, yet, with perl, we do not ship/provide a
way to communicate with them within OS. We get multiple requests from
customers/users of RHN Hosted and Satellite XML-RPC API to justify looking to
supply beyond just Satellite channels.

A minor negative about maybe adding to the RHN Tools channel, is that all
content currently in Tools is RHN/Satellite owned/coded stuff, no 3rd party code
packages within the channel.

So, going to poke RHEL PM, and see what we get back.

Mirek - what is status of getting this package into EPEL or Fedora? 

Since once we can get into say EPEL/Fedora land, have a better chance of getting into RHEL 6. 

Right now, putting package into RHN Tools is not an ideal solution to this, as everything else in Tools is purely our own code packages and not code from other sources (such as cpan). 

Cliff.

The package is in EPEL:
http://download.fedora.redhat.com/pub/epel/5/i386/repoview/perl-Frontier-RPC.html
An in Fedora:
https://admin.fedoraproject.org/pkgdb/packages/name/perl-Frontier-RPC

And I requested to include it in RHEL4.3:
https://bugzilla.redhat.com/show_bug.cgi?id=455382
https://bugzilla.redhat.com/show_bug.cgi?id=455383

Ops, I meant:
And I requested to include it in RHEL5.4.

Pushing this to sat600 as RHEL 6 and RHEL 5.4 are after Sat 5.3.0.

perl-Frontier-RPC is in RHEL since RHEL6, so it does not have sense to persued this BZ.
Closing