Latest build oops

[Dag Wieers]

On Thu, 8 Jun 2006, Dean Takemori wrote:

> 
> On Jun 7, 2006, at 12:00 AM, freshrpms-list-request at freshrpms.net wrote:
> > On Tue, 6 Jun 2006, Dag Wieers wrote:
> > 
> > > Maybe it's better to build against subversion directly instead of using
> > > older SRPMs ?
> 
> While doing so would certainly address my issue, it doesn't resolve
> the issue-behind-the-issue, which is that the rpmforge source rpm
> for that package doesn't build on FC1-type systems.

Well, it used to do. But something changed since the package was released.

I cannot maintain future-compatibility since I lack psychic abilities.


> > The change was made on 12 october 2005. Before the FC5 release bump.
> > However I made my packages on 9 march 2005 without needing the change.
> > 
> > So I'm not sure why in your case perl created the .packlist and in my case
> > it didn't. (for none of the distributions I package)
> 
> [snip]
> 
> > Maybe perl was updated in between ?
> > 
> > [root at lisse dar]# dar-exec -d fc3a rpm -qi perl
> > = Executing "rpm -qi perl" for fc3a.
> > Name        : perl                         Relocations: (not relocatable)
> > Version     : 5.8.5                             Vendor: Red Hat, Inc.
> > Release     : 24.FC3                        Build Date: Fri 16 Dec 2005
> > 08:59:51 PM CET
> > Install Date: Thu 05 Jan 2006 05:58:41 PM CET      Build Host:
> > dolly.build.redhat.com
> > Group       : Development/Languages         Source RPM:
> > perl-5.8.5-24.FC3.src.rpm
> 
> [snip]
> 
> > And indeed, the perl is not really the same. It could also be related to
> > one of the perl modules used by Makefile.PL
> 
> ~ > rpm -q perl
> perl-5.8.3-17.5.legacy
> 
> Could be, but it's not something I'm motivated in tracking down.  I'm
> simply reporting what I find in the hopes that
> 1) A fix gets rolled into the rpmforge releases, or

Well, releasing new packages/source packages in order to fix something 
like this seems more of a waste to all the users. Because they have to 
download a new releases that is not different from what they already have.

I could replace the source rpm by a newer one without changing the 
release, which is also not considered good practice.

There are other cases where we make changes to SPEC files that do not 
change the resulting binary package. Those modifications are being done 
only on the SPEC file in subversion and will only affect newer binary 
builds (either for a new distribution or for a new release).

I know this is suboptimal, but it's much better than forcing everyone to 
update a package that is identical.


> 2) If not, there will be a report in the list archives that anyone running
> into the same problems can find.

That's fine.

Kind regards,
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]