[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Dependencies [was: Re: bugs, bugs, bugs!]

On Wed, 2003-07-30 at 06:52, Michael Schwendt wrote:
> Hash: SHA1
> On Wed, 30 Jul 2003 03:41:09 +0200, Leonard den Ottolander wrote:
> >  On systems lacking a complete package database to query, the explicit 
> > naming of the depended on packages would solve the problem of unknown 
> > dependencies. Splitting a package and moving a library to a new package 
> > would possibly leave a redundant package requirement in a depending on 
> > rpm, but the requirement for the library would be still available. If a 
> > package maintainer did miss such a library split the redundant package 
> > requirement would most probably not harm and be updated as soon as 
> > spotted.
> > 
> >  Consistently mentioning both the required packages as well as the 
> > libraries would make the rpm db system more self-contained and probably 
> > solve a lot of dependency problems.
> For some packages such a list of explicit requirements can get
> pretty long and would require an extra maintenance effort. For
> instance, not only when depending packages are renamed or when the
> dependencies of a package change (user would install redundant
> stuff). But also when a particular version of a library is found
> only in a particular package revision. We should rely on tools which
> solve the dependencies for us and which find out what package to
> install to get libfoo.so.3.
> >  On systems lacking a complete package database to query,
> ... there should be an alternative way like querying a remote
> package database server.

And that is effectively how dependency-solving tools like up2date, apt,
yum, etc. work... by querying remote servers, caching appropriate
meta-deta locally, and figuring out all of this for you.  Leonard:  why
won't you use one of those tools and thus avoid this whole problem?


| Jeremy Portzer       jeremyp pobox com       trilug.org/~jeremy     |
| GPG Fingerprint: 712D 77C7 AB2D 2130 989F  E135 6F9F F7BC CC1A 7B92 |

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]