Re: making two subpackages with files in exactly the same place

[Jeff Johnson <jbj redhat com>]

On Tue, Jul 30, 2002 at 01:08:33PM +0200, Arkadiusz Miskiewicz wrote:
> 
> Hi,
> 
> This is suggestion of feature for rpm 4.1.
> 
> I have XFree86.src.rpm which contains whole xfree (including normal ati drivers)
> and separate ati.2 drivers (from gatos project). 
> 
> I want to build two subpackages:
> XFree86-driver-ati (original ati drivers from xfree)
> XFree86-driver-ati.2 (new ati drivers from gatos.sf.net)
> 
> Now the problem is that in both packages different files
> must be placed in exactly the same place for example:
> /usr/X11R6/lib/modules/drivers/r128_drv.o. Of course
> both packages will Obsolete each other. (I can't
> build ati.2 drivers from separate spec file because xfree
> sources are needed and also I thing that would be overkill).

Problem understood.

> 
> afaik this is not possible even in rpm 4.1 so I'm suggesting
> support for something like %root(number) or %root(/blah). For
> example original driver is installed at
> $RPM_BUILD_ROOT/usr/X11R6/lib/modules/drivers/r128_drv.o
> while gatos driver at
> $RPM_BUILD_ROOT/gatos/usr/X11R6/lib/modules/drivers/r128_drv.o
> and then in files section:
> 
> %files driver-ati
> %{_libdir}/modules/drivers/r128/r128_drv.o
> 
> (1)
> %files driver-ati.2
> %root(1) /gatos/%{_libdir}/modules/drivers/r128/r128_drv.o 
> 
> or
> 
> (2)
> %files driver-ati.2
> %root(/gatos) %{_libdir}/modules/drivers/r128/r128_drv.o 
> 
> or
> 
> (3)
> %files driver-ati.2
> %root(/gatos) /gatos/%{_libdir}/modules/drivers/r128/r128_drv.o 
> 

Hmmm, how about (4):

	Name: driber-ati.1
	BuildRoot: %{_tmppath}/driver-ati.1

	%package -n driver-ati.2
	BuildRoot: %{_tmppath}/driver-ati.2

where %files sections have an (assumed, maybe overridable with -r )
per-subpackage BuildRoot prefix attribute.

Permitting a per-subpackage %{buildroot} as attribute avoids the need for
additional syntax to strip the leading part of the path of a shadow
install (i.e. $RPM_BUILD_ROOT} tree entirely.

OTOH, assembling a package from components in multiple build roots
is not possible with (4). I'm not sure that's a missing (ahem) feature.

Scheme (4) also generalizes (when the time comes to permit noarch sub-packages)
by adding per-subpackage %prep/%build/%install scripts, and might even permit
nested spec file builds, i.e. the Right Thing Happens if another spec
file is simply included, all sections would map to per-subpackage sections.

The trick will be passing in sufficient info so that a single %build/%install
scriptlet can figger where to install files if subpackage build sections are
simply concatenated, something like:

	%install
	# generated by rpm
	RPM_BUILD_ROOT=%{_tmppath}/driver-ati.1-root
	RPM_BUILD_DIR=%{_builddir}/driver-ati.1
	cd $RPM_BUILD_DIR
	# included from included specfile and/or per-subpackage scriptlet
	<%install scriptlet for driver-ati.1>

	# generated by rpm
	RPM_BUILD_ROOT=%{_tmppath}/driver-ati.2-root
	RPM_BUILD_DIR=%{_builddir}/driver-ati.2
	cd $RPM_BUILD_DIR
	# included from included specfile and/or per-subpackage scriptlet
	<%install scriptlet for driver-ati.2>

Hmmm, I think I might even be able to get a %{_target_cpu} expansion
on the path for, say, a kernel or glibc per-arch subpackage build.
	
> 
> %root(number) - strip ,,number'' of dirs beginning from root
>                 directory in fileURL (this can be problematic
>                 in case of %root(2) //////bla/bla.txt and I think
>                 that any number of ,,/'' should be treated as one
>                 dir)
> %root(/gatos) - in case (2) this means: add ,,/gatos'' to diskURL
>                 (at beginning)
>               - in case (3) this means: strip out ,,/gatos'' from
>                 beginning of fileURL.
> 
> Jeff, what do you think? For me (1) is best.
> 

Iff best == easiest :-)

> Also I need suggestion how to transfer information about %root
> thing from parseForRoot() to addFile() - new field in
> struct FileList_s (ie. int rootLevel for (1)) ?

Whatever works, you can't possibly do more damage to the build code than
what's there already :-(.

I'd add a const char * pkg->buildRootURL (just like spec->buildRootURL),
and prefer (if non-NULL) the pkg over the spec buildRootURL. Changing
processBinaryFile() is where the choice between pkg->buildRootURL
vs fl->buildRootURL would be needed.

Otherwise, if you do wish to run explicit prefix's as file attribute,
making fl->buildRootURL an array is the easiest alternative. Equivalently,
wiring a Spec pointer (which has the subpackage Package list) would
permit access to the data without duplicating buildRootURL into a
FileList.

FYI, the build code is (almost certainly,) gonna be entirely rewritten
in rpm-4.2. One of the first items on the agenda is to rip out myftw
in favor of rpmio/fts.c. Note that fts(3) supports a multi-rooted
file tree walk, unlike ftw(3).

> 
> ps. I'm preparing patch doing this for rpm 4.0.4 but I don't know
>     which method I should choose.

I love patches :-)

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC