Bug 206478

This is my first package, and I am seeking a sponsor.  Thanks!

There needs some SPEC file changes. I have done it for you. Add Changelog entry
and add direct download upstream tarball URL and rebuild SRPM and post here.

Created attachment 136329 [details]
Clean SPEC file

Done.
Spec URL: http://gryffindor.jcomserv.net/yumdiff/yumdiff.spec
SRPM URL: http://gryffindor.jcomserv.net/yumdiff/yumdiff-1.0-2.src.rpm
Thanks!

Jon, are you actively working on improving yumdiff?

I am having serious doubts if this script in its current shape is ready for
inclusion in FE.

(In reply to comment #5)
> Jon, are you actively working on improving yumdiff?
> 
> I am having serious doubts if this script in its current shape is ready for
> inclusion in FE.

I've frozen any changes while working on the submission process.  What changes
or improvements do you suggest?  I'm open to any suggestions.

(In reply to comment #6)
> (In reply to comment #5)

> I've frozen any changes while working on the submission process.  What changes
> or improvements do you suggest?  I'm open to any suggestions.

What your script basically does at the moment, is fetching 
/var/log/rpmpkgs via ssh from a remote host and diff it against the local one.

1. This working principle can't work.
2. Your script produces bogus results (probably bugs)
3. Your script relies on many preliminaries on the remote host
4. ...

All in all, I feel your script to be in a very early stage.

(In reply to comment #7)
> (In reply to comment #6)
>
> What your script basically does at the moment, is fetching 
> /var/log/rpmpkgs via ssh from a remote host and diff it against the local one.
> 
> 1. This working principle can't work.
> 2. Your script produces bogus results (probably bugs)
> 3. Your script relies on many preliminaries on the remote host
> 4. ...
> 
> All in all, I feel your script to be in a very early stage.

I'm considering changing it to call rpm -qa and sort the results directly,
rather that relying on the /etc/cron.daily/rpm having run, which would likely
address #2.  As for #3, I felt if same to assume that most networked Fedora
hosts would have ssh running and rpm installed.

Could you elaborate on #1?  I'm not sure I follow what you mean.

Lacking a timely response from Ralf, is there anything I can do to move this
forward?   I'm willing to make improvements, but I need more specific examples
in order to make them . . .

(In reply to comment #9)
> Lacking a timely response from Ralf,
Hmm? Note, this package is still in FE_NEW. 
I never started formally reviewing it ;)

> is there anything I can do to move this
> forward?
Yes, may-be I had not been clear enough.

IMO, your script in its current shape is non-functional (C.f. comment #7).
=> Bring it to function.

>   I'm willing to make improvements, but I need more specific examples
> in order to make them . . .
Additional food for thought:
* What if the remote host uses a different Linux distro?
* What if the remote host doesn't use rpm or yum?
* What if the remote host is not a Linux system at all (Solaris, or even Windows)?

(In reply to comment #10)
> (In reply to comment #9)
> > Lacking a timely response from Ralf,
> Hmm? Note, this package is still in FE_NEW. 
> I never started formally reviewing it ;)
> 
> > is there anything I can do to move this
> > forward?
> Yes, may-be I had not been clear enough.
> 
> IMO, your script in its current shape is non-functional (C.f. comment #7).
> => Bring it to function.

I guess what I'm getting at is that within scope I intended, I've not run into
any problems with this script.  In what way does it not function?

> >   I'm willing to make improvements, but I need more specific examples
> > in order to make them . . .
> Additional food for thought:
> * What if the remote host uses a different Linux distro?

Yumdiff is only intended to support Fedora, currently.

> * What if the remote host doesn't use rpm or yum?

As all Fedora hosts use rpm, and Yumdiff never calls yum on the remote host, I
don't see a problem here.

> * What if the remote host is not a Linux system at all (Solaris, or even Windows)?

See #1.

> 
> 

If there are problems or improvements I can make to make this function better
with Fedora, I will.  It was never intended to make installed-software
comparisions across distros or OSs, as these comparisons could very well be
meaningless due to differences in software version, package system type, etc.

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Lacking a timely response from Ralf,
> > Hmm? Note, this package is still in FE_NEW. 
> > I never started formally reviewing it ;)
> > 
> > > is there anything I can do to move this
> > > forward?
> > Yes, may-be I had not been clear enough.
> > 
> > IMO, your script in its current shape is non-functional (C.f. comment #7).
> > => Bring it to function.
> 
> I guess what I'm getting at is that within scope I intended, I've not run into
> any problems with this script.  In what way does it not function?
Design flaw #1: The whole working principle is flawed.

You can't apply /var/log/rpmpkgs for the purpose you intend.

Just rm /var/log/rpmpkgs on the remote host and you'll see.
 
> > >   I'm willing to make improvements, but I need more specific examples
> > > in order to make them . . .
> > Additional food for thought:
> > * What if the remote host uses a different Linux distro?
> 
> Yumdiff is only intended to support Fedora, currently.
All your script does is to remotely execute a script, from inside of a python
script. It's really trivial to extend this remote script with a couple of checks
to make it more reliable.

> > * What if the remote host doesn't use rpm or yum?
> 
> As all Fedora hosts use rpm, and Yumdiff never calls yum on the remote host, I
> don't see a problem here.

> If there are problems or improvements I can make to make this function better
> with Fedora, I will.  It was never intended to make installed-software
> comparisions across distros or OSs, as these comparisons could very well be
> meaningless due to differences in software version, package system type, etc.
Design flaw #2: You are executing a script remotely. Therefore you can't rely on
any assumption.

Ok.  I'll address these issues and bring the results back here.  Thanks for the
input.

Done.
Spec URL: http://gryffindor.jcomserv.net/yumdiff/yumdiff.spec
SRPM URL: http://gryffindor.jcomserv.net/yumdiff/yumdiff-1.0-3.src.rpm

Let me know if this is sufficient.

Any update?  I've actually been working on this some more, and have a 1.1
release that allows an inverse flag, to update the remote system to match local.

New files, now with man page.

Spec URL: http://gryffindor.jcomserv.net/yumdiff/yumdiff-1.1-2.spec
SRPM URL: http://gryffindor.jcomserv.net/yumdiff/yumdiff-1.1-2.src.rpm

A suggestion,
Considering that most of the discussion so far concerns the basic functionality
and not packaging issues, I think it would be worthwhile for you to open up a
discussion on fedora-extras-list or on the upstream yum development list and get
feedback from the community as to the underlying design and functionality aims,
before continuing with a submission request.  

-jef

Good idea.  I'll write something up and run it up the flagpole.  Thanks.

(In reply to comment #17)
> A suggestion,
> Considering that most of the discussion so far concerns the basic functionality
> and not packaging issues, I think it would be worthwhile for you to open up a
> discussion on fedora-extras-list or on the upstream yum development list and get
> feedback from the community as to the underlying design and functionality aims,
> before continuing with a submission request.  
> 
> -jef
> 

New files, reflecting new "ignore version info"feature"

Spec URL: http://gryffindor.jcomserv.net/extras/yumdiff/yumdiff-1.2-1.spec
SRPM URL: http://gryffindor.jcomserv.net/extras/yumdiff/yumdiff-1.2-1.src.rpm

Will be posting to f-e-l for community brainstorm shortly. . .

Removing FE-NEEDSPONSOR, sponsored through limph review.

Following discussion on f-e-l, withdrawing review request to work on re-vamping
yumdiff.  Thanks to all for suggestions, criticism, feedback, etc.