re:Virtual package: postscript-preview
On Fri, 12 Jan 1996, brian (b.c.) white wrote:
> >> If two packages provide "postscript-preview", will it be considered a
> >> conflict? If so, then this might not be a good idea. There may be
> >> cases where people want two different postscript viewers on their machine.
AISI, two packages providing the same virtual package don't conflict,
they augment. ISTM that depends and conflicts are handled other ways.
> >
> >It was my understanding that the provides field was created specificaly
> >so that more than one package could provide a feature, thus releaving
> >depends from having to specify multiple package dependance when really
> >only one feature needed to be supplied.
>
> This is my understanding, too, and it makes complete sense in the case
> where there can logically only be one present at a time. Sendmail/Smail
> is a perfect example with the "mail-transport-agent" virtual package.
>
Yes! While they both provide a "mail-transport-agent" they *may* also
conflict, and some packages may depend on one but not the other. It is
only for those packages that don't care who the "mail-transport-agent"
is, that the virtual provides is of any use.
> But when it comes to packages that provide the same functionality but
> can peacefully coexist, what then? The best example for this might be
> a virtual package of the name "editor". I use emacs, but if somebody
> who shares my machine (or my /usr mount, for that matter) wants to use
> vi, then both could not provide the virtual package "editor" if it
> will cause a conflict. The same goes for multiple postscript viewer
> packages.
I'm not sure how vi and emacs might *conflict*. More than the user who
wants to use it, there are packages that may prefer vi to emacs (for
instance news readers that use vi as the default editor) but again this
is a depends issue not a conflicts.
>
> If virtual packages are going to be used for the purpose you suggest
> (and I think they should be), then there must be a way to specify that
> a virtual package is supplied non-exclusively so that other packages
> can also supply the same virtual package without conflicting.
>
It is my understanding that provides is a non-conflicting feature of a
package and that conflicts are dealt with via other methodologies.
BTW, this discussion began when I asked if it was ok to add a new vp to
the list, rather than the more fundamental underlying principles of the
provides field. On the other hand I have certainly gained from the
discussion so far.
For our silent listeners, is there anything in this area that Brian or I
have failed to realize/comprehend/discuss?
YHS,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 877-0257
Flexible Software Fax: NONE
Black Creek Critters e-mail: dwarf@polaris.net
------------ If you don't see what you want, just ask --------------
Reply to: