Re: support for manual file dependencies ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Good day -

I've attached a patch against RPM 4.13.0 source that makes RPM verify file
system dependencies which are not owned by any package in the RPM-DB .

The patch adds one new C file:
   lib/rpm_fs_deps.c
and a header:
   lib/rpm_fs_deps.h
Which is used by lib/depends.c, @line 706, in unsatisfiedDepend() :
<quote>
unsatisfied:
    if (dsflags & RPMSENSE_MISSINGOK) {
	/* note the result, but missingok deps are never unsatisfied */
	rpmdsNotify(dep, "(missingok)", 1);
    } else {
        if (! rpm_fs_dep_satisfied ( rpmdsN( dep ) ) )
	{ /* dependency is unsatisfied */
            rc = 1;
            rpmdsNotify(dep, NULL, rc);
        }
    }
</quote>

I added the files to lib/Makefile.am, and did a 'autoreconf -fiv' in
the top-level RPM source directory,  and then reran configure and
built and installed the package OK .

The new rpm_fs_dep_satisfied() function handles both dependencies
like 'libc.so.6' , which are handled by verifying that a file of that name
exists in any directory listed in the ld.so.conf configuration ( the ld.so.conf
files are loaded, handling 'include ...*' statements, by the second new function
in rpm_fs_deps.c, 'load_ld_so_conf()' ),   OR dependencies like
'/usr/include/stdio.h' , which are satisfied if the file exists .

Now, with the patch, RPM actually does what it says (or implies) on the tin
and actually DOES verify file dependencies, regardless of whether they are
provided by any  installed  package or not .

Please consider implementing something like this patch in the next
release of RPM.

Thanks & Regards,
Jason

On 20/06/2017, Jason Vas Dias <jason.vas.dias@xxxxxxxxx> wrote:
> Good day Orion - thanks for your response!
> RE: > File deps work just fine
> No, they don't!
> I did mention both %{includedir}/stdio.h and
> %{_includedir}/stdio.h, and even /usr/include/stdio
> and just 'stdio.h'  in my mail - apologies for the spelling
> typos - I did try them all.
>
> But none of these strings will cause RPM to recognize such
> a dependency as being satisfied if there is no RPM in the
> RPM database that Provides that file , regardless of whether
> it exists in the filesystem or not .
>
> I analysed the code in the RPM source :
>     build/spec.c   :  rpmSpecCheckDeps()
>     lib/depends.c :  rpmtsCheck()
>
> All that code does is search the existing RPM database ;
> if no RPM is recorded as Provide-ing a file in the database,
> it returns false - it does not do any check for the existence
> of a file in the file system.
>
> There appears to be no way to get RPM to check for the existence
> of an arbitrary file in the file system .
>
> I'd suggest developing a patch to make it do so , to enable RPM to more
> easily be able to start off the process of dividing OS files into packages
> BEFORE any RPM package has yet been defined;  basically, if rpmtsCheck()
> returns "problems", then check if the dependency string  actually names an
> existing file or not , and consider the dependency satisfied if it does .
>
> But I have verified there is NO such code in current versions of RPM .
>
> Could any of the RPM developers please advise whether such a patch will
> ever be entertained / considered / developed ?
>
> Thanks & Best Regards,
> Jason
>
> P.S.
> here is a test .spec fle with a dependency on /usr/include/stdio.h :
>
> <quote>
> name: T
> version: 1
> release: 1
> license: GPL
> summary: Test Spec File Capabilities
> %define  breq  /usr/include/stdio.h
> %define  req   libc.so.6
> BuildRequires: %breq %req
> Requires        : %req
> source: T.spec
> %description
>  %{summary}
> %build
> true
> %install
> cp T.spec %{buildroot}/%{name}-%{release}-%{version}.%{arch}
> %files
> %defattr (-,root,root,-)
> T.spec
> %changelog
> * Mon Jun 19 2017 jason.vas.dias@xxxxxxxxx
>   - created.
> </quote>
>
> Attempts to build fail:
>
> $  rpmbuild -vvv -bp /tmp/T.spec --define _topdir' '/tmp --define
> _builddir' '/tmp --define _buildrootdir' '/tmp --define _srcdir' '/tmp
> --build-in-place
> ufdio:       1 reads,    16960 total bytes in 0.000033 secs
> error: Failed build dependencies:
> 	/usr/include/stdio.h is needed by T-1-1.x86_64
> 	libc.so.6 is needed by T-1-1.x86_64
>
> I want to make RPM in this situation:
>   1. Check for existence of /usr/include/stdio.h , satisfying
> dependency if found
>   2. Check for existence of libc.so.6 in any directory in the default
> system
>       ld.so(1) path as constructed from contents of /etc/ld.so.conf or
>       /etc/ld.so.conf.d/* .
>
> It demonstrably does not do this.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 19/06/2017, Orion Poplawski <orion@xxxxxxxxxxxxx> wrote:
>> On 06/19/2017 10:08 AM, Jason Vas Dias wrote:
>>> Hi -
>>>
>>> I am wondering why RPM supports automatic dependencies like:
>>> ' Requires : libc.so.6
>>> '
>>> but does not allow things like :
>>> ' BuildRequires: %{includedir}/stdio.h
>>
>> File deps work just fine, but this should be %{_includedir}/stdio.h.
>>
>>
>> --
>> Orion Poplawski
>> Technical Manager                          720-772-5637
>> NWRA, Boulder/CoRA Office             FAX: 303-415-9702
>> 3380 Mitchell Lane                       orion@xxxxxxxx
>> Boulder, CO 80301                   http://www.nwra.com
>>
>

Attachment: RPM-4.13.0-fs_deps.patch
Description: Binary data

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux