debian/control: enhanced version dependencies?
Hi folks,
For running a local set of meta packages I would like to
express package dependencies depending upon other packages
installed, e.g.
Package: xyz
Version: all
Depends: ${misc:Depends}
, dbus (systemd >= 215)
Hopefully you get the meaning. Package xyz could make sure
that dbus is installed, if systemd is installed. (systemd
version 215 itself just recommends dbus.)
Another example:
Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 (kde-full >= 5:66)
, mykde2 (kde-full >= 5:77)
, mykde3 (kde-full >= 5:84)
Package mykde1
:
:
Do you think this could be possible? Are there other
options for debian/control to express complex package
dependencies?
Regards
Harri
Re: debian/control: enhanced version dependencies?
On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
> For running a local set of meta packages I would like to
> express package dependencies depending upon other packages
> installed, e.g.
>
> Package: xyz
> Version: all
> Depends: ${misc:Depends}
> , dbus (systemd >= 215)
>
> Hopefully you get the meaning.
I'm not sure I do.
> Package xyz could make sure
> that dbus is installed, if systemd is installed. (systemd
> version 215 itself just recommends dbus.)
What if systemd isn't installed? Nothing happens?
>
>
> Another example:
>
> Package: mykde
> Version: all
> Depends: ${misc:Depends}
> . kde-full
> , mykde1 (kde-full >= 5:66)
> , mykde2 (kde-full >= 5:77)
> , mykde3 (kde-full >= 5:84)
>
> Package mykde1
> :
> :
This is even less clear.
--
WBR, wRAR
Re: debian/control: enhanced version dependencies?
Andrey Rahmatullin, on Thu 14 Jan 2016 14:11:36 +0500, wrote:
> On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
> > Package: xyz
> > Version: all
> > Depends: ${misc:Depends}
> > , dbus (systemd >= 215)
Perhaps something like this
dbus | systemd (<< 215) | !systemd
?
Samuel
Re: debian/control: enhanced version dependencies?
On 01/14/2016 10:11 AM, Andrey Rahmatullin wrote:
> On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
>> For running a local set of meta packages I would like to
>> express package dependencies depending upon other packages
>> installed, e.g.
>>
>> Package: xyz
>> Version: all
>> Depends: ${misc:Depends}
>> , dbus (systemd >= 215)
>>
>> Hopefully you get the meaning.
> I'm not sure I do.
>
>> Package xyz could make sure
>> that dbus is installed, if systemd is installed. (systemd
>> version 215 itself just recommends dbus.)
> What if systemd isn't installed? Nothing happens?
>
Thats what I was trying to express.
>>
>>
>> Another example:
>>
>> Package: mykde
>> Version: all
>> Depends: ${misc:Depends}
>> . kde-full
>> , mykde1 (kde-full >= 5:66)
>> , mykde2 (kde-full >= 5:77)
>> , mykde3 (kde-full >= 5:84)
>>
>> Package mykde1
>> :
>> :
> This is even less clear.
>
In this example mykde depends upon kde-full and a set of other
packages, depending upon the version of kde-full.
I am not proud of the syntax, either. Surely you have a better
suggestion about how to express this kind of package dependencies.
Regards
Harri
Re: debian/control: enhanced version dependencies?
On 15/01/16 09:33, Harald Dunkel wrote:
> On 01/14/2016 10:11 AM, Andrey Rahmatullin wrote:
>> On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
>>> For running a local set of meta packages I would like to
>>> express package dependencies depending upon other packages
>>> installed, e.g.
>>>
>>> Package: xyz
>>> Version: all
>>> Depends: ${misc:Depends}
>>> , dbus (systemd >= 215)
>>>
>>> Hopefully you get the meaning.
>> I'm not sure I do.
>>
>>> Package xyz could make sure
>>> that dbus is installed, if systemd is installed. (systemd
>>> version 215 itself just recommends dbus.)
>> What if systemd isn't installed? Nothing happens?
>>
> Thats what I was trying to express.
>
>>>
>>> Another example:
>>>
>>> Package: mykde
>>> Version: all
>>> Depends: ${misc:Depends}
>>> . kde-full
>>> , mykde1 (kde-full >= 5:66)
>>> , mykde2 (kde-full >= 5:77)
>>> , mykde3 (kde-full >= 5:84)
>>>
>>> Package mykde1
>>> :
>>> :
>> This is even less clear.
>>
> In this example mykde depends upon kde-full and a set of other
> packages, depending upon the version of kde-full.
>
> I am not proud of the syntax, either. Surely you have a better
> suggestion about how to express this kind of package dependencies.
>
The '|' character to express a condition is already taken,
and so are the parentheses.
How about some Perl-like post-annotation as in
Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 if kde-full >= 5:66
, mykde2 if kde-full >= 5:77
, mykde3 if kde-full >= 5:84
This way you can mix the two semantics
Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 (>= 4.99)if kde-full >= 5:66
, mykde1 (>= 5.0) if kde-full >= 5:77
How long will it take until someone implements tic-tac-toe
with Debian package dependencies? Just kidding.
If the package maintainers get this right, then I
think these logics would indeed help to get Debian systems
leaner and possibly also more stable. But I primarily see
some beauty that intrigues me.
Steffen
Re: debian/control: enhanced version dependencies?
On Thu, 14 Jan 2016 09:35:31 +0100, Harald Dunkel wrote:
> Hi folks,
>
> For running a local set of meta packages I would like to express package
> dependencies depending upon other packages installed, e.g.
>
> Package: xyz
> Version: all
> Depends: ${misc:Depends}
> , dbus (systemd >= 215)
dbus | systemd < 215
>
> Hopefully you get the meaning. Package xyz could make sure that dbus is
> installed, if systemd is installed. (systemd version 215 itself just
> recommends dbus.)
>
>
> Another example:
>
> Package: mykde
> Version: all
> Depends: ${misc:Depends}
> . kde-full
> , mykde1 (kde-full >= 5:66)
kde-full < 5:66 | mykde1
> , mykde2 (kde-full >= 5:77)
kde-full < 5:77 | mykde2
> , mykde3 (kde-full >= 5:84)
kde-full < 5:84 | mykde3
>
> Package mykde1 :
> :
>
> Do you think this could be possible? Are there other options for
> debian/control to express complex package dependencies?
You are trying to create implications. a => b is the same as !a || b,
which is how I expressed the dependencies above. This is easy to do for
versioned dependencies, but not so easy for non-versioned ones (you
cannot have !package in the Depends field, there is the Conflicts field
but that is another grouping). You could work around that limitation by
imposing a (<< 0~) restriction to packages that should not be installed
in any version.
This may make the package difficult to install, however, because apt only
considers one version per package as candidate.
--
Saludos,
Felipe Sateler
Re: debian/control: enhanced version dependencies?
Felipe Sateler, on Fri 15 Jan 2016 12:33:37 +, wrote:
> On Thu, 14 Jan 2016 09:35:31 +0100, Harald Dunkel wrote:
>
> > Hi folks,
> >
> > For running a local set of meta packages I would like to express package
> > dependencies depending upon other packages installed, e.g.
> >
> > Package: xyz
> > Version: all
> > Depends: ${misc:Depends}
> > , dbus (systemd >= 215)
>
> dbus | systemd < 215
In the meant purpose you'd need also
| !systemd
which is not supported.
Samuel
Re: debian/control: enhanced version dependencies?
On Fri, 15 Jan 2016 13:56:55 +0100, Samuel Thibault wrote:
> Felipe Sateler, on Fri 15 Jan 2016 12:33:37 +, wrote:
>> On Thu, 14 Jan 2016 09:35:31 +0100, Harald Dunkel wrote:
>>
>> > Hi folks,
>> >
>> > For running a local set of meta packages I would like to express
>> > package dependencies depending upon other packages installed, e.g.
>> >
>> > Package: xyz Version: all Depends: ${misc:Depends}
>> >, dbus (systemd >= 215)
>>
>> dbus | systemd < 215
>
> In the meant purpose you'd need also
>
> | !systemd
>
> which is not supported.
Ah, you are correct. !(x (>> v)) is not (x (<= v)). It doesn't seem to
be possible then.
--
Saludos,
Felipe Sateler
Re: debian/control: enhanced version dependencies?
Hi, Quoting Felipe Sateler (2016-01-15 13:33:37) > You are trying to create implications. a => b is the same as !a || b, which > is how I expressed the dependencies above. This is easy to do for versioned > dependencies, but not so easy for non-versioned ones (you cannot have > !package in the Depends field, there is the Conflicts field but that is > another grouping). You could work around that limitation by imposing a (<< > 0~) restriction to packages that should not be installed in any version. Implications like a=>b can be expressed via a third package c which conflicts with a. You'd then have: Package: xyz Depends: c | b Package: c Conflicts: a Whenever discussions about new dependency syntax come up I like to remind people of all the time (about six years now) and effort it took to get the build profile syntax [1] accepted by the archive, supported by all tools and to sufficiently discuss this with everybody involved to get general agreement that this is necessary and we're doing it the right way. And this is not even over yet as that syntax has to be documented in policy as well! Plus, we are only talking about Build-Depends syntax here. I'd assume that there are even more tools that handle binary package Depends syntax that the 19 that handle source package dependency syntax. In this case, the desired effect can be achieved using existing elements of the dependency syntax and without any unreadable version quirks. A new syntax would *only* be acceptable if there were hundreds if not thousands of packages that would benefit from an easier way to express such a conditional and in which case having all these meta-packages I proposed as a solution above would become infeasible. Thanks! cheers, josch [1] https://wiki.debian.org/BuildProfileSpec signature.asc Description: signature
Re: debian/control: enhanced version dependencies?
Hi folks, On 01/15/2016 05:07 PM, Johannes Schauer wrote: > > Whenever discussions about new dependency syntax come up I like to remind > people of all the time (about six years now) and effort it took to get the > build profile syntax [1] accepted by the archive, supported by all tools and > to > sufficiently discuss this with everybody involved to get general agreement > that > this is necessary and we're doing it the right way. And this is not even over > yet as that syntax has to be documented in policy as well! Plus, we are only > talking about Build-Depends syntax here. I'd assume that there are even more > tools that handle binary package Depends syntax that the 19 that handle source > package dependency syntax. > > In this case, the desired effect can be achieved using existing elements of > the > dependency syntax and without any unreadable version quirks. A new syntax > would > *only* be acceptable if there were hundreds if not thousands of packages that > would benefit from an easier way to express such a conditional and in which > case having all these meta-packages I proposed as a solution above would > become > infeasible. > I understand that the existing package dependency options are already very complex, especially if all the "Conflicts", "Recommends" and "Provides" options are taken into account. > Thanks! > Thanx very much to all for your feedback. Keep on your good work Harri
