On Sat, Jun 21, 2008 at 3:05 PM, Jeff Johnson <n3npq@mac.com>
wrote:

On Jun 21, 2008, at 7:16 AM, devzero2000 wrote:

Two naive/luser questions :

- how to reproduce, i think it is necessary,  the deb soft deps <-> rpm
upstream  (e.g. not the SuSe ) soft deps translation ? Do you thinks exists
1-1 corrispondence ?


Debian Suggests: and Recommends: end up as a message displayed
during install afaik (I can point to a post from Gustavo Niemeyer saying
exactly that if necessary).

Perhaps this one

http://lists.opensuse.org/opensuse-packaging/2005-12/msg00071.html

The debian docu is accurate on this

http://www.debian.org/doc/debian-policy/ch-relationships.html



Enhances: ends up as merge of metadata from the package containing
the Enhances: to the another package that is mentioned. That merge
can be undertaken whenever there is a clear RPM usage case.
In the far narrower context of adding --deb:contains spewage, or possibly
attempting
to teach rpmbuild how to produce *.deb packages, there are only syntax,
not semantic, issues. What dpkg/apt do with "soft" dependencies is
up to the dpkg/apt implementation, providing a means to specify the
"soft" dependencies within specfiles, and generating the debian/control file
accurately, are the only issues for rpmbuild.

I agreed

- This is histerical i suppose, so sorry in advance : if it is possible to
translate file  deps to package deps, the only deps deb know, why are rpm
file deps necessary ? Or, posted in other way, the rebutal nr. 7 of "Reply:
Top 10 Problems with RPM" (http://tinyurl.com/6p9emx)  is it always valid
for you ?


RPM file dependencies are not "necessary". They are useful for many reasons,
mostly
because package names cannot be reliably determined when building a package
in general.

I agreed also: it is exactly this that i don't like when i am building deb
sometime. And, iirc, it was  one  of the reason, not the only, to use
sometime the rpm5 runtime probe deps executable(<command>), other that issue
on some deps resolver as anaconda (sometime ago almost, now anaconda are
using yum), instead of just Requires: <package that provide command>. What
is more,  but perhaps i disgress, file deps based on run time probe
dependency are very  useful  if i mix rpm and, for example, aix lslpp
package where i don't have control over lslpp package name evolution. Other
example where the file deps are useful are  the "context  marked
dependency".

I still believe that this engineering statement is valid and accurate today:

RPM computes a "contains" relationship to map all — package, soname, file,
foo(bar), … — dependency tokens to the package that resolves the dependency.
The cost of the mapping is quite modest using any standard technique (rpm
uses bsearch because of portability) to associate a key with a value. Add
–stats to any rpm command to measure the overhead for your specific
benchmark.


I believe also.


Thanks for your reply