Thomas Lockhart wrote:
> > Well, what I had in mind was have a unified RPM tree, single SRPM, with
> Oh. Since there was already an RPM->redhat-RPM, it was pretty clear that
> we would be segregating the RPM files. Will rearrange asap.
Sorry for the misunderstanding -- originally I had wanted it with a
'redhat-RPM', 'SuSE-RPM', etc structure -- so I went ahead and created
(and linked to) redhat-RPM -- then, I realized the nightmare of multiple
source RPM's, and symlinked 'RPM' to 'redhat-RPM' so as to not break the
existing link(s). The next PostgreSQL version (major or minor) will
have just the 'RPM' dir instead of 'redhat-RPM' and the symlink, unless
it is felt by us that segregating the RPMs is better for the userbase.
> > If you want to follow Mandrake naming conventions (-2mdk) that's fine,
> > but not necessary as being in the 'mandrake-7.x' dir should set them
> > apart.
> That would seem to be problematic, since it would be difficult to tell
> them apart outside the context of the Postgres ftp site. Don't know how
> to assign a different version for different vendors within the RPM,
> though I've gotten hints from your communications that it would be
> possible. Also...
Yes, this would be possible. There are macros available to the spec
file that can change the output filename. This is why (I think)
mandrake chose to put the -mdk on theirs.
> > As a matter of necessity, you will be needing to upgrade to RPM 3.0.5 to
> > do any RPM building from these src RPMs in the future, more than
> > likely.
> Hmm. So we are forcing an "RPM fork"? I'm running rpm-3.0.4 on a
> Mandrake machine, and your current 7.0.2-2 rpms build just fine. What
> new features are we getting with the update? Can an rpm built with 3.0.5
> be installed with a previous version of rpm (I would assume so, but just
The only new feature 3.0.5 has over 3.0.4, IIRC, is ability to read
rpm-4 source RPM's. There _are_ a number of bugfixes, however. With
RPM 3.0.5 installed, there will still only need to be a single source
RPM, potentially in rpm-4 format. I'm not sold on why a major format
change was required, but, then again, I've not dug into it at that
level. Yeah, I guess you could say we are forcing a 'fork' of sorts --
but the split was kindof forced on us, if we want to continue providing
'canonical' RPMs that distributions can ship -- easing somewhat the
Binaries built with RPM 3.0.5 will install just fine on any RPM3 system,
RPM 4, OTOH, is a major upgrade, and is likely one of the major upgrades
that necessitated this RedHat release being version 7.0. The biggest
change that I know of is a lowlevel major version upgrade of Berkeley
DB, causing the very database format to be very incompatible with prior
> It seems like we will need to carry along two versions of the RPMs for a
> while, since RedHat is pushing for new, incompatible versions of these
> builds on *their* release cycle (though perhaps Mandrake is up the curve
> on this; don't know myself).
We will need to carry both 'redhat-6.x' and 'redhat-7.x' trees at least
until Red Hat 8.0 is released. This is the same thing that happened
with 5.2 -- which I really should reinstall to get newer RPM's onto it,
as it is still officially supported by RedHat.
WGCR Internet Radio
1 Peter 4:11
In response to
pgsql-hackers by date
|Next:||From: Thomas Swan||Date: 2000-08-01 17:27:35|
|Subject: Re: RPMs built for Mandrake|
|Previous:||From: Kovacs Zoltan Sandor||Date: 2000-08-01 16:26:55|
|Subject: pg_dump and pg_restore, speed|