RE: On Jun 21, 2017, at 4:03 AM, Panu Matilainen <pmatilai@xxxxxxxxxx> <mailto:pmatilai@xxxxxxxxxx> 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@xxxxxxx> wrote: > > >> Begin forwarded message: >> >> From: Jeffrey Johnson <n3npq@xxxxxxx> >> Subject: Fwd: support for manual file dependencies ? >> Date: June 21, 2017 at 4:18:15 AM EDT >> To: rpm-devel@xxxxxxxx >> >> >> >>> Begin forwarded message: >>> >>> Since I am likely still censored on <rpm-list@xxxxxxx >>> <mailto:rpm-list@xxxxxxx>>, I will reply here as well. >>> >>>> Begin forwarded message: >>>> >>>> From: Jeffrey Johnson <n3npq@xxxxxx <mailto:n3npq@xxxxxx>> >>>> 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@xxxxxxxxxxxxx <mailto:rpm-list@xxxxxxxxxxxxx>> >>>> >>>> >>>>> On Jun 21, 2017, at 4:03 AM, Panu Matilainen <pmatilai@xxxxxxxxxx >>>>> <mailto:pmatilai@xxxxxxxxxx>> 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@xxxxxxxx <mailto:rpm-devel@xxxxxxxx>> >>> archives … I’ll dig them out if there is any serious interest. >>> >>> hth >>> >>> 73 de Jeff >>> >>> >> > >
Attachment:
RPM-4.13.0-fs_deps.patch
Description: Binary data
Attachment:
rpm_spec_from_build.sh
Description: Bourne shell script
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
