On Wed, Apr 16, 2008, Jeff Johnson wrote:

> On Apr 16, 2008, at 8:31 AM, Ralf S. Engelschall wrote:
>> On Wed, Apr 16, 2008, devzero2000 wrote:
>>
>>> Sorry, Ralf. Only a curiosity on OPENPKG packaging.
>>>
>>> Why most package have:
>>>
>>> AutoReq:      no
>>> AutoReqProv:  no
>>>
>>> I doesn't like this never. OTHO i like automatic dependency resolution .
>>>
>>> Sure, it is also true that i am lazy
>>
>> The auto-dependency resolution in RPM is mainly a Linux-specific or
>> at least system-specific thing. It automatically adds dependencies to
>> system shared libraries, etc. This is both useless and unnecessary for a
>> self-contained cross-platform software distribution like OpenPKG. There
>> all(!) dependencies have to be within the software distribution _ONLY_
>> and not to any artefacts outside of it (like system libraries). Hence
>> all dependencies are explicitly configured and no implicit ones are
>> required. So, don't compare OpenPKG's use of RPM with the RPM use of a
>> usual operating system vendor. OpenPKG has completely different goals
>> and hence different constraints. OpenPKG is about using RPM for managing
>> an independent software stack on top of an operating system, but not
>> about managing an operating system itself...
>
> I understand the distinction quite well.
>
> But there are times that "independent" needs to import (or export) certain
> information that crosses the OS <-> managed set boundary.
>
> How do you handle, say, libc.so.6 dependencies? Implicitly with, say,
> a targeted collection? That works sure.

Libc dependency is implictly, i.e., OpenPKG just has a few system
requirements which have to be fulfilled, but which are not explicitly
checked for. Libc is one of them. Other like the tar(1) and make(1)
tools for bootstrapping are explicitly checked, but not via RPM
mechanism. Instead the %build script of the "openpkg" bootstrap package
check for those tools manually (which is necessary as the "openpkg.spec"
is a "special" RPM specification, as it has to be run via RPM and
without RPM -- by emulating a small subset of RPM via plain /bin/sh
during bootstrapping).

> The reason for asking is that I'm looking for ways that /etc/rpm/sysinfo
> (one of 2 approaches tried by rpm, the other is packages to carry
> native OS Provides:) might be improved.

In OpenPKG we neither use /etc/rpm/sysinfo nor Provides for system
parts. If OpenPKG really requires a system part it uses a proxy package.
For instance, package "proftpd" when requring PAM, requires the "pam"
package which itself checks in its %build that all includes and libs are
available. This was the only portable way to achieve those dependencies
to external stuff, as one has to do totally different things on
different platforms.
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com