Thread: RPMs built for Mandrake

Hi Lamar. I got around to building 7.0.2 RPMs for Mandrake, and afaict
your .src.rpm built without trouble. It even got the ".bz2" man page
compression right (of course, without explicitly doing this in the spec
file).

Will post on ftp.postgresql.org soon. Is a new RPM coming out before the
next Postgres release?
                    - Thomas

> Will post on ftp.postgresql.org soon...

I've posted .src and .i686 Mandrake RPMs for Postgres-7.0.2 built on
mdk-7.1 at
 ftp://ftp.postgresql.org/pub/binary/Mandrake/

The Mandrake/ directory will move to /pub/binary/v7.0.2/Mandrake once
the permissions are fixed up: Lamar, can you please adjust the group
permissions to allow pgsql to write into those directories (and to move
around files, just in case)? Should we adjust the names on the
directories from RPM and redhat-RPM to "redhat" only (or "RedHat" or ??)
to get some symmetry with the other distros?

When I have a chance, I'll go ahead and make some .i586 versions, unless
someone else beats me to it...
                       - Thomas

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
> checking...)?

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
support burden.

Binaries built with RPM 3.0.5 will install just fine on any RPM3 system,
AFAIK.

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
releases.
> 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.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

> >   ftp://ftp.postgresql.org/pub/binary/Mandrake/
> > The Mandrake/ directory will move to /pub/binary/v7.0.2/Mandrake once
> > the permissions are fixed up: Lamar, can you please adjust the group
> > permissions to allow pgsql to write into those directories (and to move
> > around files, just in case)? Should we adjust the names on the
> > directories from RPM and redhat-RPM to "redhat" only (or "RedHat" or ??)
> > to get some symmetry with the other distros?
> Well, what I had in mind was have a unified RPM tree, single SRPM, with
> multiple binary RPM trees.  So, since someone else has fixed the group
> perms on that tree already (thanks Jeff or Marc), pop the Mandrake
> binary RPMs into pub/binary/v7.0.2/RPM/RPMS/mandrake-7.x (the dir is
> already created).

Oh. Since there was already an RPM->redhat-RPM, it was pretty clear that
we would be segregating the RPM files. Will rearrange asap.

> If there had been departures from the main RPMset source RPM, then we
> would need the source RPM as well uploaded -- but, as long as the build
> is simply a rpm --rebuild (or equivalent), then there's no need to use
> the space for an essentially identical file.
> 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...

> 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
checking...)?

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).
                        - Thomas

Thomas Lockhart wrote:
>   ftp://ftp.postgresql.org/pub/binary/Mandrake/
> The Mandrake/ directory will move to /pub/binary/v7.0.2/Mandrake once
> the permissions are fixed up: Lamar, can you please adjust the group
> permissions to allow pgsql to write into those directories (and to move
> around files, just in case)? Should we adjust the names on the
> directories from RPM and redhat-RPM to "redhat" only (or "RedHat" or ??)
> to get some symmetry with the other distros?

Well, what I had in mind was have a unified RPM tree, single SRPM, with
multiple binary RPM trees.  So, since someone else has fixed the group
perms on that tree already (thanks Jeff or Marc), pop the Mandrake
binary RPMs into pub/binary/v7.0.2/RPM/RPMS/mandrake-7.x (the dir is
already created).

If there had been departures from the main RPMset source RPM, then we
would need the source RPM as well uploaded -- but, as long as the build
is simply a rpm --rebuild (or equivalent), then there's no need to use
the space for an essentially identical file.

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.

As to a new RPM version, yes on both interpretations -- there is/will be
a new version of the PostgreSQL RPM's before the next major PostgreSQL
release, and there will also be a new major version of RPM itself before
the next major PgSQL release.  The RPM's from the public RedHat beta
release should, until I post newer ones, be considered the current
version -- and, since the release of the public beta, I will be posting
newer RPM's this week.

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.  And, if you want to poke around with the src RPM from the
RedHat beta, you will have to upgrade to RPM 3.0.5 in order to even read
the src rpm, as the RedHat beta is using RPM 4.0-format RPMs.  RPM 4.0
should be in a released state by the time PgSQL releases a new major
version.  And I can now say that since the beta is public ~;-).  So, you
should be seeing more updates to the RPMset now.

And I want to give many kudos and thanks to Trond Eivind Glomsrød, who
has been shepherding the RPMset through the labyrinthine update publicly
known as Pinstripe.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

> Will post on ftp.postgresql.org soon. Is a new RPM coming out before the
> next Postgres release?

RPM 3.0.5 has already been released, and is available from ftp.rpm.org

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

-
- Thomas Swan                                   
- Graduate Student  - Computer Science
- The University of Mississippi
-
- "People can be categorized into two fundamental
- groups, those that divide people into two groups
- and those that don't."