support for manual file dependencies ?

[Jason Vas Dias]

RE: On Jun 21, 2017, at 4:03 AM, Panu Matilainen <pmatilai at redhat.com>
<mailto:pmatilai at redhat.com> wrote:
> Um, what isn't packaged cannot be depended on. That is a pretty
> fundamental feature of package management.

That has been a fundamental feature of RPM package management, yes -
I believe that is one of RPM's fundamental design flaws .

Since you cannot specify a dependency on any unpackaged file, dependency cycles
between packages are very likely to occur.

Consider the 'ncurses' and 'gpm' packages for example. You cannot
build gpm without ncurses headers and libraries, and to support the
mouse in the terminal, you cannot build ncurses without the gpm headers.
The only way to break such cycles is to install the binary package '*-devel'
from one or the other. But what if you are trying to start with a
'clean system'
and want only to install packages you have built ? Then you have to first  build
ncurses without GPM, install the ncurses-devel package, and then build GPM ,
and then rebuild ncurses with GPM support.
All this could be avoided if ncurses and gpm could simply specify
dependencies on
each other's headers (or library provides), which can be verified as
existing in the file system without having to be packaged.

The attached patch makes RPM verify file system dependencies like
'/usr/include/stdio.h' or 'libc.6.so' without them having to be owned
by any package - it is a very simple and robust patch.

The beauty of this is as soon as you install a glibc package that Provides these
capabilities , RPM would  transparently translate them into
 'Requires: glibc-devel, glibc'  ;
but you do not have to have a pre-existing glibc RPM installed in order to
specify a dependency on a library or header file.

Really, there needs to be a way to specify dependency on a file system
object, to say 'Regardless of what provides this file, this package cannot be
built without it'  .

It also makes it much simpler to generate spec files from autoconf builds ,
as the attached 'rpm_spec_from_build.sh' script does - it can simply
run the C-pre-processor to generate '-M' make dependency output,
and parse it to generate a list of  headers, and run 'readelf -d' on each
binary or library produced  to produce a list of library dependencies.

Thus the attached patch makes it much easier to generate package
.spec files without developers having to write .spec files.

So I hope RPM will eventually see sense and implement something like the
attached patch.

RPM5 sounds interesting - I will investigate - I did not know about it - if
it supports file system dependencies, it is already much more capable than
RPM-4. But RPM-4 with the attached patch is what I need to get started
packaging the files of a small embedded system.

Thanks for all your responses,
Regards,
Jason Vas Dias

On 21/06/2017, Jeffrey Johnson <n3npq at mac.com> wrote:
>
>
>> Begin forwarded message:
>>
>> From: Jeffrey Johnson <n3npq at mac.com>
>> Subject: Fwd: support for manual file dependencies ?
>> Date: June 21, 2017 at 4:18:15 AM EDT
>> To: rpm-devel at rpm5.org
>>
>>
>>
>>> Begin forwarded message:
>>>
>>> Since I am likely still censored on <rpm-list at rpm.org
>>> <mailto:rpm-list at rpm.org>>, I will reply here as well.
>>>
>>>> Begin forwarded message:
>>>>
>>>> From: Jeffrey Johnson <n3npq at me.com <mailto:n3npq at me.com>>
>>>> Subject: Re: support for manual file dependencies ?
>>>> Date: June 21, 2017 at 4:09:36 AM EDT
>>>> To: General discussion about the RPM package manager
>>>> <rpm-list at lists.rpm.org <mailto:rpm-list at lists.rpm.org>>
>>>>
>>>>
>>>>> On Jun 21, 2017, at 4:03 AM, Panu Matilainen <pmatilai at redhat.com
>>>>> <mailto:pmatilai at redhat.com>> wrote:
>>>>>
>>>>>
>>>>> Um, what isn't packaged cannot be depended on. That is a pretty
>>>>> fundamental feature of package management.
>>>>> 	
>>>>
>>>> Um, what is present on the file system (or sonames present in a library)
>>>> can be tested for dynamically
>>>> without the tyranny of having to package and install an RPM in an
>>>> rpmdb.
>>>>
>>>> A dynamic test that can be reproduced with external tools is at least as
>>>> dependendable
>>>> as a file that is registered in an rpmdb but has been removed on the
>>>> file system.
>>>>
>>>> 73 de Jeff
>>>>
>>>
>>> FYI:
>>>
>>> RPM5 has a set of probe dependencies that can dynamically check
>>> assertions
>>> on any file that can be passed to access(2) (this includes all the
>>> functionality implemented
>>> in access(2) flags).
>>>
>>> This is also true for sonames from libraries that were installed (by
>>> “make install”).
>>>
>>> The are details in the <rpm-devel at rpm5.org <mailto:rpm-devel at rpm5.org>>
>>> archives … I’ll dig them out if there is any serious interest.
>>>
>>> hth
>>>
>>> 73 de Jeff
>>>
>>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RPM-4.13.0-fs_deps.patch
Type: application/octet-stream
Size: 5044 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20170621/342aa836/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpm_spec_from_build.sh
Type: application/x-sh
Size: 17876 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20170621/342aa836/attachment-0001.sh>