Handling directories in rpm (was Re: %files...)

<snip>
> >> There are several obvious resolutions to
conflicts, including
> >>     1) least/most restrictive permission
and/or context
> >>     2) first install "wins"
> >>     3) last install "wins"
> >>     4) whatever is on the file system
"wins" (i.e. don't change
> >> existing).
> >> Each of the above has various pro's and con's,
but any of the above
> >> is likelier to be more deterministic and
reproducible (because rule
> >> based) than the incoherent and arbitrary
policies that are
currently
> >> widely deployed in *.rpm packages.
> >
> > Or 5) Treat it like any other file conflict.
> >
> 
> Conflict detection ain't gud enuf for end users imho.
> 
> "OK. So directories are in conflict. Full stop.
Lovely, let's go
> bitch on IRC
> and mailing lists about the issue."
At some point you have to ignore the bitching if it's the
right thing to
do.
As you know I'm perfectly happy with full stop, as it
prevents packaging
the many of the properties of dung from leaving the door. 
There is no
chance to forget about it.  I'm also a fan of overrides such
as your dep
whiteout, where one can make a conscious decision to ignore
an issue.
So if you had a full stop behavior with some way of saying
ignore this
one in the configs, then IMO were done.

> 
> Been there, done that. I believe that predictable
resolution, like
> preferring
> most-restrictive or vendor of configured or ... when
there is a
> conflict needs
> to be attempted.
I prefer deterministic, because that which is deterministic
is no longer
a gamble, and who wouldn't want to bet their jobs on it.

All that said I really like the idea of directory
dependencies.  It
seems a natural heuristic for ordering packages. 

Cheeers...james
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On 10/31/06, Oden, James <James.Odentekelec.com> wrote:
> <snip>
> > >> There are several obvious resolutions to
conflicts, including
> > >>     1) least/most restrictive permission
and/or context
> > >>     2) first install "wins"
> > >>     3) last install "wins"
> > >>     4) whatever is on the file system
"wins" (i.e. don't change
> > >> existing).
> > >> Each of the above has various pro's and
con's, but any of the above
> > >> is likelier to be more deterministic and
reproducible (because rule
> > >> based) than the incoherent and arbitrary
policies that are
> currently
> > >> widely deployed in *.rpm packages.
> > >
> > > Or 5) Treat it like any other file conflict.
> > >
> >
> > Conflict detection ain't gud enuf for end users
imho.
> >
> > "OK. So directories are in conflict. Full
stop. Lovely, let's go
> > bitch on IRC
> > and mailing lists about the issue."


> At some point you have to ignore the bitching if it's
the right thing to
> do.

I easily shrug off bitching, until it leads to slander with
my name attached.

> As you know I'm perfectly happy with full stop, as it
prevents packaging
> the many of the properties of dung from leaving the
door.  There is no
> chance to forget about it.  I'm also a fan of overrides
such as your dep
> whiteout, where one can make a conscious decision to
ignore an issue.
> So if you had a full stop behavior with some way of
saying ignore this
> one in the configs, then IMO were done.
>

Sure "full stop" is a perfectly valid resolution
to conflicts. Its by
no means the
only, or the "best" solution.

(aside) I suspect that it ins't obvious that I think that
rpm needs to attempt
*all* of the above resolutions, including "full
stop", as well as "fifo",
"lifo", "do nothing", "least"
and "most" restrictive.

Each of the above implementations is rather straightforward,
and
has an applicable solution domain for some set of rpm users.

So rather than try and dictate The One True Way, I'd rather
see
multiple conflict resolutions implemented that can be
changed
through configuration, not by (incompatibly) changing the
implementation.

Then the only thing left to decide is what the
"default" rpm configuration
should be, which, since I distribute and use my own version
of rpm,
I'm perfectly capable of doing all by my widdle self 

> >
> > Been there, done that. I believe that predictable
resolution, like
> > preferring
> > most-restrictive or vendor of configured or ...
when there is a
> > conflict needs
> > to be attempted.
> I prefer deterministic, because that which is
deterministic is no longer
> a gamble, and who wouldn't want to bet their jobs on
it.
>
> All that said I really like the idea of directory
dependencies.  It
> seems a natural heuristic for ordering packages.
>

Yeah, me too. A directory hierarchy, unlike the reasons not
to put
spaces in file names, is simple to understand and
communicate, and (if
symlinks are ignored) is quite
objective, reliable, unambiguous, non-controversial
dependency
ordering relations.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On 10/31/06, Oden, James <James.Odentekelec.com> wrote:
> <snip>
> > >> There are several obvious resolutions to
conflicts, including
> > >>     1) least/most restrictive permission
and/or context
> > >>     2) first install "wins"
> > >>     3) last install "wins"
> > >>     4) whatever is on the file system
"wins" (i.e. don't change
> > >> existing).
> > >> Each of the above has various pro's and
con's, but any of the above
> > >> is likelier to be more deterministic and
reproducible (because rule
> > >> based) than the incoherent and arbitrary
policies that are
> currently
> > >> widely deployed in *.rpm packages.
> > >
> > > Or 5) Treat it like any other file conflict.
> > >
> >
> > Conflict detection ain't gud enuf for end users
imho.
> >
> > "OK. So directories are in conflict. Full
stop. Lovely, let's go
> > bitch on IRC
> > and mailing lists about the issue."


> At some point you have to ignore the bitching if it's
the right thing to
> do.

I easily shrug off bitching, until it leads to slander with
my name attached.

> As you know I'm perfectly happy with full stop, as it
prevents packaging
> the many of the properties of dung from leaving the
door.  There is no
> chance to forget about it.  I'm also a fan of overrides
such as your dep
> whiteout, where one can make a conscious decision to
ignore an issue.
> So if you had a full stop behavior with some way of
saying ignore this
> one in the configs, then IMO were done.
>

Sure "full stop" is a perfectly valid resolution
to conflicts. Its by
no means the
only, or the "best" solution.

(aside) I suspect that it ins't obvious that I think that
rpm needs to attempt
*all* of the above resolutions, including "full
stop", as well as "fifo",
"lifo", "do nothing", "least"
and "most" restrictive.

Each of the above implementations is rather straightforward,
and
has an applicable solution domain for some set of rpm users.

So rather than try and dictate The One True Way, I'd rather
see
multiple conflict resolutions implemented that can be
changed
through configuration, not by (incompatibly) changing the
implementation.

Then the only thing left to decide is what the
"default" rpm configuration
should be, which, since I distribute and use my own version
of rpm,
I'm perfectly capable of doing all by my widdle self 

> >
> > Been there, done that. I believe that predictable
resolution, like
> > preferring
> > most-restrictive or vendor of configured or ...
when there is a
> > conflict needs
> > to be attempted.
> I prefer deterministic, because that which is
deterministic is no longer
> a gamble, and who wouldn't want to bet their jobs on
it.
>
> All that said I really like the idea of directory
dependencies.  It
> seems a natural heuristic for ordering packages.
>

Yeah, me too. A directory hierarchy, unlike the reasons not
to put
spaces in file names, is simple to understand and
communicate, and (if
symlinks are ignored) is quite
objective, reliable, unambiguous, non-controversial
dependency
ordering relations.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Tuesday, 31 October 2006, at 09:26:57 (-0500),
Jeff Johnson wrote:

> We agree. The corollary question is
>     Should the install package tree always be
setup<- 
> filesystem<-...<-glibc-common?
> 
> That was the intended order a long time ago (for
largely hysterical
> reasons), but the behavior since RHL 6.2 has permitted
leaf nodes
> (i.e. pkgs with no dependencies) to be installed
whenever they are
> encountered.

One could argue, though, that when considering parent
directories as
dependencies, concepts such as "packages with no
dependencies" cease
to exist.  Unless, of course, they have no dependencies
*and* install
no files/directories...in which case their usefulness
immediately
comes into question.  

> Consider the segfault that the glibc cabal inflicted on
everyone
> last June when they started caching passwd lookups. The
cabal forgot
> (since remedied) to refresh the cache when useradd was
run in %post,
> hence rpm was installing all files in chroot as
root.root. One of
> the suggestions at the time (which is also patched into
ALT linux's
> rpm) was to parse /etc/passwd directly, instead of
calling
> getpwent(3).

So the solution to fixing a bug in glibc was to have RPM
bypass the
entire nsswitch mechanism and manually parse the passwd
file?  Oh
dear...I seem to have left my logic in my other pants.

> So there's an implicit dependency on the existence of
/etc/passwd in
> all packages through the user.group strings attached to
files.

One thing I've always wondered...why not store the userid's
*and* the
numeric UID values in the RPM metadata and create users on
the fly as
needed?  Or providing some other, more "official"
mechanism, for
creating/depending on user accounts?

> The dependency on /etc/passwd lookup used to be handled
by
> installing setup as the first package (hysterically),
has been
> handled since RHL 6.2 by pre-caching all user.group
owners of files
> in packages that must be installed before getpwent(3)
lookup in the
> chroot is functional.

Pre-caching...from where?  The main system?

> Ironically, the glibc cabal has also decided that
> 	AutoRequires: no
> is the correct way to package glibc. I've repeatedly
pointed out the
> need for /etc/passwd by rpm in chroot's privately. Oh
well ...

It is not in the nature of a cabal to subscribe to reasoning
which
conflicts with their accepted doctrines.

> So parent directory dependencies used for ordering are
a objective
> way of forcing the package that contains "/"
(and incidentally /etc/
> passwd) to be installed first, so that either a
parser-in-rpm, or
> equivalently, more deterministic pre-caching of
user.group lookups
> until getpwent(3) in the chroot is functional, will
occure
> naturally.
> 
> Got that?  Silly stupid
problem, massive overkill solution.

heh

> (aside) There's the further issue of whether lookups
should be done
> outside or inside the chroot, there are reasonable
arguments both
> ways.

"Both" is what comes to my mind, but we can leave
that aside...aside. 

> Perfectly sensible. The hard decisions are what to do
when
> directories that should be the same, aren't. Consider
umask(2) and
> local sysadmin modification side effects.

But if I make a manual change to, say, permissions on
/usr/local, and
I (re)install the package which provides it, the expectation
would be
that those changes would, or at least could, be lost.  The
permanent
solution, should I want to make it such, would be to create
my own
package to replace the old system one.

> Snarly loops that I did not want to deal with that
afternoon, I was
> adding erasure ordering at the time. Useful specific
behavior
> details will be shared when seen.

Fair enough.

> Increasingly, manually added dependencies are creating
more problems
> than they solve. Luckily, manually added dependencies
are marked as
> such. What is needed is more objective rules for adding
> dependencies, and better means to verify correctness
and ...

Automation of dependency gathering and otherwise is a
continual
recitation of the mantra:  Bigger, Better, Faster, More! 
But I'm not
sure quantifying all of the assorted smaller, worse, slower,
or less
in the current system is germane to the discussion at hand.


> I'm not sure I agree, note "logical end-point
..."  disclaimer 

I saw, and I'm wondering what the ramifications would be in
your
estimation.  It seems to me that storing all those
basename/dirname
ownerships would have significant implications on the DB
side.  Or am
I being too literal?

> Conflict detection ain't gud enuf for end users imho.

You'll notice I didn't *choose* that option...just noted it
for the
sake of completeness.

> The counter argument is to prefer 3) because the last
action that
> was performed determines what is on the file system,
principle of
> least surprise.

True, assuming the last action is allowed to rule.  Granted,
doing
otherwise would involve post-install owner/perm
"cleanups" by RPM....




On Tuesday, 31 October 2006, at 08:53:23 (-0600),
Oden, James wrote:

> I prefer deterministic, because that which is
deterministic is no
> longer a gamble, and who wouldn't want to bet their
jobs on it.
> 
> All that said I really like the idea of directory
dependencies.  It
> seems a natural heuristic for ordering packages.

I agree.



On Tuesday, 31 October 2006, at 11:26:42 (-0500),
Jeff Johnson wrote:

> (aside) I suspect that it ins't obvious that I think
that rpm needs
> to attempt *all* of the above resolutions, including
"full stop", as
> well as "fifo", "lifo", "do
nothing", "least" and "most"
> restrictive.

FWIW, it was not obvious at least to me.   But I
think you're right.

> So rather than try and dictate The One True Way, I'd
rather see
> multiple conflict resolutions implemented that can be
changed
> through configuration, not by (incompatibly) changing
the
> implementation.

Could this be extended to other conflicts as well, such as
traditional
file conflicts?  Seems like essentially the same problem
being solved
to me.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "I now cry streams of blood because I had to take my
stand.  I crush
  my eyes beneath my heel as my heart pulses in my
hand."
                                                         --
"Forsaken"
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Tuesday, 31 October 2006, at 09:26:57 (-0500),
Jeff Johnson wrote:

> We agree. The corollary question is
>     Should the install package tree always be
setup<- 
> filesystem<-...<-glibc-common?
> 
> That was the intended order a long time ago (for
largely hysterical
> reasons), but the behavior since RHL 6.2 has permitted
leaf nodes
> (i.e. pkgs with no dependencies) to be installed
whenever they are
> encountered.

One could argue, though, that when considering parent
directories as
dependencies, concepts such as "packages with no
dependencies" cease
to exist.  Unless, of course, they have no dependencies
*and* install
no files/directories...in which case their usefulness
immediately
comes into question.  

> Consider the segfault that the glibc cabal inflicted on
everyone
> last June when they started caching passwd lookups. The
cabal forgot
> (since remedied) to refresh the cache when useradd was
run in %post,
> hence rpm was installing all files in chroot as
root.root. One of
> the suggestions at the time (which is also patched into
ALT linux's
> rpm) was to parse /etc/passwd directly, instead of
calling
> getpwent(3).

So the solution to fixing a bug in glibc was to have RPM
bypass the
entire nsswitch mechanism and manually parse the passwd
file?  Oh
dear...I seem to have left my logic in my other pants.

> So there's an implicit dependency on the existence of
/etc/passwd in
> all packages through the user.group strings attached to
files.

One thing I've always wondered...why not store the userid's
*and* the
numeric UID values in the RPM metadata and create users on
the fly as
needed?  Or providing some other, more "official"
mechanism, for
creating/depending on user accounts?

> The dependency on /etc/passwd lookup used to be handled
by
> installing setup as the first package (hysterically),
has been
> handled since RHL 6.2 by pre-caching all user.group
owners of files
> in packages that must be installed before getpwent(3)
lookup in the
> chroot is functional.

Pre-caching...from where?  The main system?

> Ironically, the glibc cabal has also decided that
> 	AutoRequires: no
> is the correct way to package glibc. I've repeatedly
pointed out the
> need for /etc/passwd by rpm in chroot's privately. Oh
well ...

It is not in the nature of a cabal to subscribe to reasoning
which
conflicts with their accepted doctrines.

> So parent directory dependencies used for ordering are
a objective
> way of forcing the package that contains "/"
(and incidentally /etc/
> passwd) to be installed first, so that either a
parser-in-rpm, or
> equivalently, more deterministic pre-caching of
user.group lookups
> until getpwent(3) in the chroot is functional, will
occure
> naturally.
> 
> Got that?  Silly stupid
problem, massive overkill solution.

heh

> (aside) There's the further issue of whether lookups
should be done
> outside or inside the chroot, there are reasonable
arguments both
> ways.

"Both" is what comes to my mind, but we can leave
that aside...aside. 

> Perfectly sensible. The hard decisions are what to do
when
> directories that should be the same, aren't. Consider
umask(2) and
> local sysadmin modification side effects.

But if I make a manual change to, say, permissions on
/usr/local, and
I (re)install the package which provides it, the expectation
would be
that those changes would, or at least could, be lost.  The
permanent
solution, should I want to make it such, would be to create
my own
package to replace the old system one.

> Snarly loops that I did not want to deal with that
afternoon, I was
> adding erasure ordering at the time. Useful specific
behavior
> details will be shared when seen.

Fair enough.

> Increasingly, manually added dependencies are creating
more problems
> than they solve. Luckily, manually added dependencies
are marked as
> such. What is needed is more objective rules for adding
> dependencies, and better means to verify correctness
and ...

Automation of dependency gathering and otherwise is a
continual
recitation of the mantra:  Bigger, Better, Faster, More! 
But I'm not
sure quantifying all of the assorted smaller, worse, slower,
or less
in the current system is germane to the discussion at hand.


> I'm not sure I agree, note "logical end-point
..."  disclaimer 

I saw, and I'm wondering what the ramifications would be in
your
estimation.  It seems to me that storing all those
basename/dirname
ownerships would have significant implications on the DB
side.  Or am
I being too literal?

> Conflict detection ain't gud enuf for end users imho.

You'll notice I didn't *choose* that option...just noted it
for the
sake of completeness.

> The counter argument is to prefer 3) because the last
action that
> was performed determines what is on the file system,
principle of
> least surprise.

True, assuming the last action is allowed to rule.  Granted,
doing
otherwise would involve post-install owner/perm
"cleanups" by RPM....




On Tuesday, 31 October 2006, at 08:53:23 (-0600),
Oden, James wrote:

> I prefer deterministic, because that which is
deterministic is no
> longer a gamble, and who wouldn't want to bet their
jobs on it.
> 
> All that said I really like the idea of directory
dependencies.  It
> seems a natural heuristic for ordering packages.

I agree.



On Tuesday, 31 October 2006, at 11:26:42 (-0500),
Jeff Johnson wrote:

> (aside) I suspect that it ins't obvious that I think
that rpm needs
> to attempt *all* of the above resolutions, including
"full stop", as
> well as "fifo", "lifo", "do
nothing", "least" and "most"
> restrictive.

FWIW, it was not obvious at least to me.   But I
think you're right.

> So rather than try and dictate The One True Way, I'd
rather see
> multiple conflict resolutions implemented that can be
changed
> through configuration, not by (incompatibly) changing
the
> implementation.

Could this be extended to other conflicts as well, such as
traditional
file conflicts?  Seems like essentially the same problem
being solved
to me.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "I now cry streams of blood because I had to take my
stand.  I crush
  my eyes beneath my heel as my heart pulses in my
hand."
                                                         --
"Forsaken"
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

In regard to: [Rpm-devel] Re: Handling directories in rpm,
Michael Jennings...:

> On Tuesday, 31 October 2006, at 09:26:57 (-0500),
> Jeff Johnson wrote:
>
>> We agree. The corollary question is
>>     Should the install package tree always be
setup<-
>> filesystem<-...<-glibc-common?
>>
>> That was the intended order a long time ago (for
largely hysterical
>> reasons), but the behavior since RHL 6.2 has
permitted leaf nodes
>> (i.e. pkgs with no dependencies) to be installed
whenever they are
>> encountered.
>
> One could argue, though, that when considering parent
directories as
> dependencies, concepts such as "packages with no
dependencies" cease
> to exist.  Unless, of course, they have no dependencies
*and* install
> no files/directories...in which case their usefulness
immediately
> comes into question.  

Those types of packages are very useful on non-Linux (or
non-RPM Linux
systems), because they can be used to set up a default set
of "things"
that are provided outside of RPM's control (like by some
other packaging
system).

You're right that they aren't very useful on Linux systems
that have
RPM as the package management system.

Tim
-- 
Tim Mooney                                          
Tim.Mooneyndsu.edu
Information Technology Services                      (701)
231-1076 (Voice)
Room 242-J6, IACC Building                           (701)
231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Tuesday, 31 October 2006, at 18:18:06 (-0600),
Tim Mooney wrote:

> >One could argue, though, that when considering
parent directories as
> >dependencies, concepts such as "packages with
no dependencies" cease
> >to exist.  Unless, of course, they have no
dependencies *and* install
> >no files/directories...in which case their
usefulness immediately
> >comes into question.  
> 
> Those types of packages are very useful on non-Linux
(or non-RPM Linux
> systems), because they can be used to set up a default
set of "things"
> that are provided outside of RPM's control (like by
some other packaging
> system).

Packages without dependencies, by definition, cannot
"provide"
anything outside RPM's control.  No provides, no requires,
no
obsoletes, no conflicts.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "Only those whose lives are brief can imagine that
love is eternal.
  You should embrace that remarkable illusion.  It may be
the greatest
  gift your race has ever received."           --
Lorien, Babylon Five
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

In regard to: Re: [Rpm-devel] Re: Handling directories in
rpm, Michael...:

> On Tuesday, 31 October 2006, at 18:18:06 (-0600),
> Tim Mooney wrote:
>
>>> One could argue, though, that when considering
parent directories as
>>> dependencies, concepts such as "packages
with no dependencies" cease
>>> to exist.  Unless, of course, they have no
dependencies *and* install
>>> no files/directories...in which case their
usefulness immediately
>>> comes into question.  
>>
>> Those types of packages are very useful on
non-Linux (or non-RPM Linux
>> systems), because they can be used to set up a
default set of "things"
>> that are provided outside of RPM's control (like by
some other packaging
>> system).
>
> Packages without dependencies, by definition, cannot
"provide"
> anything outside RPM's control.  No provides, no
requires, no
> obsoletes, no conflicts.

Please elaborate, as I'm afraid I'm not understanding what
apparently
should be obvious.


$rpm -q -l -p SUNWlibsx-1.0.4-1.x86_64.rpm
(contains no files)
$rpm -q --requires -p SUNWlibsx-1.0.4-1.x86_64.rpm
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
$rpm -q --provides -p SUNWlibsx-1.0.4-1.x86_64.rpm
libX11.so.4
libXext.so.0
libXaw.so.5
libXt.so.4
libXm.so.4
libXmu.so.4
libXp.so.1
libXi.so.5
libXpm.so.4
libICE.so.6
libSM.so.6
SUNWlibsx = 1.0.4-1


Tim
-- 
Tim Mooney                                          
Tim.Mooneyndsu.edu
Information Technology Services                      (701)
231-1076 (Voice)
Room 242-J6, IACC Building                           (701)
231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Tuesday, 31 October 2006, at 22:13:47 (-0600),
Tim Mooney wrote:

> Please elaborate, as I'm afraid I'm not understanding
what apparently
> should be obvious.
> 
> 
> $rpm -q -l -p SUNWlibsx-1.0.4-1.x86_64.rpm
> (contains no files)
> $rpm -q --requires -p SUNWlibsx-1.0.4-1.x86_64.rpm
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(CompressedFileNames) <= 3.0.4-1
> $rpm -q --provides -p SUNWlibsx-1.0.4-1.x86_64.rpm
> libX11.so.4
> libXext.so.0
> libXaw.so.5
> libXt.so.4
> libXm.so.4
> libXmu.so.4
> libXp.so.1
> libXi.so.5
> libXpm.so.4
> libICE.so.6
> libSM.so.6
> SUNWlibsx = 1.0.4-1

I think you're defining "dependencies" as
"requires."  Provides,
Obsoletes, and Conflicts also contain dependency metadata
(i.e.,
"dependencies").

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "I always wait until a jury has spoken before I
anticipate what they
  will do."                          -- US Attorney
General Janet Reno
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel