Hi -
I am wondering why RPM supports automatic dependencies like:
' Requires : libc.so.6
'
but does not allow things like :
' BuildRequires: %{includedir}/stdio.h
'
I am investigating providing RPM packaging support for a small
embedded system , which originally is built much like LFS:
http://linuxfromscratch.org
, from a set of Makefiles, and without RPM .
As a way to 'bootstrap' such a system to provide support for RPM
packaging, I am trying to generate .spec files where all BuildRequires
are expressed as automatic-style 'library dependencies' like 'libc.so.6' ,
AND as HEADER dependencies, on files like '%{_includedir}/stdio.h' .
RPM already does provide some sort of 'virtual capability' for members
of the files list of installed RPMs, doesn't it? ; so, when a spec
file mentions a
requirement on say '%{_includedir}/stdio.h', or perhaps just 'stdio.h',
it should know that the glibc-devel package provides this capability.
Can't .spec files mention requirements on executables like:
'BuildRequires: /usr/bin/sed
' ? If not, why not ? If so, why doesn't it work for eg. /usr/include/stdio.h ?
But, eg. before the glibc RPM has been built, and only the unpackaged
glibc is installed, then RPM should take the existence of
'%{includedir}/stdio.h'
as satisfying the capability .
Is there any way of specifying a dependancy on the existence of an arbitrary
un-packaged file in the file system with the existing RPM (I am
running 4.13.0) ?
Or is there some page where the COMPLETE requires / capability syntax is
described ? I can only find documentation of parts of it.
Thanks & Regards,
Jason
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
