[arch-general] alternate dependencies?
Hi, Seeing the earlier post re. tetex and texlive perhaps there is a case for extending pacman to support alternate dependencies. By this I mean a package could depend on one of a choice of packages. The syntax could be something like: depends=( tetex|texlive ) where the individual dependencies retain their current features e.g. versions etc. Opinions welcomed. Regards, Neil Darlow
Neil Darlow wrote:
Hi,
Seeing the earlier post re. tetex and texlive perhaps there is a case for extending pacman to support alternate dependencies.
By this I mean a package could depend on one of a choice of packages. The syntax could be something like:
depends=( tetex|texlive )
where the individual dependencies retain their current features e.g. versions etc.
Opinions welcomed.
That's what provisions are for.
Hi, Xavier wrote:
That's what provisions are for.
Wouln't that require that e.g. tetex and texlive have something like? provides=( "tex" ) In practice, how many packages include such a generic provides entry? From what I've seen most packages' depends rely solely on the package name. I think there will always be a case where an alternate dependency would better be specified by the package name. Regards, Neil Darlow
On Mon, Apr 21, 2008 at 10:20 AM, Neil Darlow <neil@darlow.co.uk> wrote:
Wouln't that require that e.g. tetex and texlive have something like?
provides=( "tex" )
In practice, how many packages include such a generic provides entry? From what I've seen most packages' depends rely solely on the package name.
I think there will always be a case where an alternate dependency would better be specified by the package name.
You can use a virtual tex provision, but you don't need to. Since the packages probably already depend on "tetex", you only need to have texlive provide tetex and that's it. Maybe it even already does?
On Mon, Apr 21, 2008 at 3:20 AM, Neil Darlow <neil@darlow.co.uk> wrote:
Hi,
Xavier wrote:
That's what provisions are for.
Wouln't that require that e.g. tetex and texlive have something like?
provides=( "tex" )
In practice, how many packages include such a generic provides entry? From what I've seen most packages' depends rely solely on the package name.
dcron provides cron. bash provides sh. These seem pretty generic to me.
I think there will always be a case where an alternate dependency would better be specified by the package name.
What you suggest seems like something that can always be done using the existing provisions logic, so I don't see it happening. -Dan
participants (3)
-
Dan McGee
-
Neil Darlow
-
Xavier