Google SoC 2008

[Anders F Björklund]

Randall Wood wrote:

> As far as the complexity of RPM goes, I think that a lot of the
> dp-light work is still hanging around and may be reusable, but it may
> simply be a good idea for port to do a Portfile to .spec file
> transform (and maybe build the SRPM) and then hand everything off to
> an RPM-based configure/build/distribute/install process. I know that a
> lot of the GTK/GNOME ports already build the .spec files for creating
> the [S]RPMs anyway.

Isn't that what the current "rpm" and "srpm" targets do ?

"rpm" was formerly known as "rpmpackage", and uses RPM
just as an archiver to package up a pre-created destroot
while filling in some basic metadata and dependencies,
but it doesn't really use the .spec file for building:

%prep
%build
%install
%clean

There is also a new "srpm" target, that creates a SRPM
(Source RPM) which contains the Portfile and all files/.
RPM doesn't have a Tcl script handler (yet?), so it calls
on port(1) to do the various operations in the RPM phases:

%prep
%setup -c -a 1 -T
cp -p %{SOURCE0} Portfile
#prepare work area
port fetch
port checksum
port extract
port patch

%build
port configure
port build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT
port destroot
port rpm

%clean
port clean

This way, the RPM is comparable to the tgz/tgz/tlz/xar
archives and the SRPM is comparable to the xar portpkg.
(as you might be aware of, MPWA creates such portpkg
for all port submissions - at http://db.macports.org)


But the registry/install/upgrade/uninstall hasn't been
updated with the rest of the dp_light stuff, that added
the capability to use RPM packages instead of archives.
(somewhat like Fink uses DEB packages to do installs...)

--anders