> would it be possible to support combined dependencies,
> e.g. if package A and B are installed, then package C(A)
> has to be installed, too?
>
> That might be helpful for dkms packages, for example.
> A would be the kernel, B the dkms package, and C(A)
> would be the headers for A.
>
What event would induce installation of C(A)?! Let's assume neither A nor B are
installed.
apt-get install A
(no point installing C(A))
apt-get install B
(B does not depend on C(A), otherwise this discussion is pointless)
... time passes ...
magic install C(A)
???
Isn't all you want a hard dependency of dkms on both the Linux kernel and its
header package? It seems that right now this is just a Recommends. Could you
maybe elaborate why a proper Depends: is not appropriate in your opinion?
Best,
Michael
08-20-2011, 06:57 AM
Sven Joachim
combined dependencies?
On 2011-08-20 08:19 +0200, Harald Dunkel wrote:
> Hi folks,
>
> would it be possible to support combined dependencies,
> e.g. if package A and B are installed, then package C(A)
> has to be installed, too?
Not unless you implement that yourself. Requests for such features in
dpkg have been wontfixed¹².
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aab4605e.fsf@turtle.gmx.de">http://lists.debian.org/87aab4605e.fsf@turtle.gmx.de
08-20-2011, 11:31 AM
Adam Borowski
combined dependencies?
On Sat, Aug 20, 2011 at 07:55:10AM +0100, Michael Tautschnig wrote:
> Hi Harri,
>
> > would it be possible to support combined dependencies,
> > e.g. if package A and B are installed, then package C(A)
> > has to be installed, too?
> >
> > That might be helpful for dkms packages, for example.
> > A would be the kernel, B the dkms package, and C(A)
> > would be the headers for A.
>
> What event would induce installation of C(A)?! Let's assume neither A nor B are
> installed.
>
> apt-get install A
> (no point installing C(A))
> apt-get install B
> (B does not depend on C(A), otherwise this discussion is pointless)
>
> ... time passes ...
>
> magic install C(A)
> ???
No, you can't install B without C(A) if A is installed, that's the whole
point of conditional dependencies. Thus at the second command apt would
pull in C(A) or throw an error if it's uninstallable.
If A is installed, B gains Depends:C(A).
If B is installed, A effectively gains Depends:C(A).
If you try to install A and B in one go, C(A) will go in as well.
If you try to uninstall C(A), either A or B has to be uninstalled.
The semantics are pretty obvious to me, it's the number of corner cases and
complexity that this brings what stops dpkg/apt/aptitude/100-other-tools
maintainers from implementing that.
(Let's rename "C(A)" to "C" for now, the former name makes no sense except
when talking about dkms.)
Logically, what you want is: !(A & B & !C)
This is: C | !A | !B
Technically, you could already get this effect by introducing a dummy
package no-B that "Breaks: B" and having A "Depend: C | no-B".
In the case of dkms, there's one dkms and many kernels so B=dkms, A=kernels.
Too bad, linux-image-$FOO depending on linux-headers-$FOO|no-dkms would be
too ugly to live. Just think of confusing messages from apt...
This could be done by no-B being a new kind of a virtual package, but I for
one don't volunteer to code that.
--
1KB // Yo momma uses IPv4!
08-20-2011, 03:08 PM
Lars Wirzenius
combined dependencies?
On Sat, Aug 20, 2011 at 01:31:11PM +0200, Adam Borowski wrote:
> The semantics are pretty obvious to me, it's the number of corner cases and
> complexity that this brings what stops dpkg/apt/aptitude/100-other-tools
> maintainers from implementing that.
What is the use case for this?
(If I missed in the thread so far, my apologies. A reply with the
Message-ID or URL would be appreciated.)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110820150803.GA19647@havelock.liw.fi">http://lists.debian.org/20110820150803.GA19647@havelock.liw.fi
08-20-2011, 04:09 PM
"John D. Hendrickson and Sara Darnell"
combined dependencies?
Lars Wirzenius wrote:
On Sat, Aug 20, 2011 at 01:31:11PM +0200, Adam Borowski wrote:
The semantics are pretty obvious to me, it's the number of corner cases and
complexity that this brings what stops dpkg/apt/aptitude/100-other-tools
maintainers from implementing that.
What is the use case for this?
(If I missed in the thread so far, my apologies. A reply with the
Message-ID or URL would be appreciated.)
there are already developers working on packaging problems that already need being solved. infact
in my spare time I am looking at one aspect
this is a nice discussion, basic logic from a text book - freshman work, yet i somehow feel it's
impertinent: these things are easier said than done, you haven't made no impact statement, you've
not posted any patch to (dpkg, apt, aptitutde, etc). there are other problems too.
i suggest two things:
1) not starting from the standpoint that someone else is specifying and completing your project for
you in a deficit economy.
2) assuming if you spend allot of time making what already has problems needing solved (dpkg) more
complicated you need OPM (other people's money) to do so, so to speak
3) remember that dependancies evolve from involuntary compile and install conflicts. what I'm
saying is that software is supposed to install and uninstall in Debian without conflicting with
other software or causing problems
4) remember that installed software CAN ALREADY EXECUSTE "dpkg -i $x" so you dont' need an automated
system to do so for that reason
the software I'm writing maybe could do what you asked when finished however i wouldn't suggest
using it that way
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E4FDC3C.1030707@cox.net">http://lists.debian.org/4E4FDC3C.1030707@cox.net
08-20-2011, 09:55 PM
Harald Dunkel
combined dependencies?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Michael,
On 08/20/11 08:55, Michael Tautschnig wrote:
>
> What event would induce installation of C(A)?! Let's assume neither A nor B are installed.
>
> apt-get install A (no point installing C(A)) apt-get install B (B does not depend on C(A), otherwise this discussion is pointless)
>
B _does_ depend on C(A), if A is installed.
> ... time passes ...
>
> magic install C(A) ???
>
>
> Isn't all you want a hard dependency of dkms on both the Linux kernel and its header package? It seems that right now this is just a Recommends. Could you maybe elaborate why a proper Depends: is not appropriate in your opinion?
>
Its not any header package: dkms needs the _appropriate_ header
package matching the installed kernel package. If
linux-image-2.6.39-1-amd64 is installed, then dkms needs
linux-headers-2.6.39-1-amd64. If linux-image-3.0-1-amd64 is
installed in parallel, then dkms needs linux-headers-3.0-1-amd64,
too.
Its just an example, anyway.
Regards
Harri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E502D42.5010506@afaics.de">http://lists.debian.org/4E502D42.5010506@afaics.de
08-21-2011, 03:51 AM
Charles Plessy
combined dependencies?
Le Sat, Aug 20, 2011 at 08:19:09AM +0200, Harald Dunkel a écrit :
>
> would it be possible to support combined dependencies,
> e.g. if package A and B are installed, then package C(A)
> has to be installed, too?
>
> That might be helpful for dkms packages, for example.
> A would be the kernel, B the dkms package, and C(A)
> would be the headers for A.
Dear Harald and everybody,
just for the record, this proposition looks very similar to another
proposition about «*conditional recommends*» in May this year.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110821035122.GC24368@merveille.plessy.net">http://lists.debian.org/20110821035122.GC24368@merveille.plessy.net
08-21-2011, 03:55 AM
Charles Plessy
combined dependencies?
Le Sun, Aug 21, 2011 at 12:51:22PM +0900, Charles Plessy a écrit :
>
> just for the record, this proposition looks very similar to another
> proposition about «*conditional recommends*» in May this year.
>
> https://lists.debian.org/1305977099.4715.47.camel@tomoyo
Here is the correct URL: http://lists.debian.org/1305977099.4715.47.camel@tomoyo
Sorry for the noise,
--
Charles
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110821035510.GA24924@merveille.plessy.net">http://lists.debian.org/20110821035510.GA24924@merveille.plessy.net
08-24-2011, 12:16 PM
Michael Tautschnig
combined dependencies?
Hi all,
[...]
>
> No, you can't install B without C(A) if A is installed, that's the whole
> point of conditional dependencies. Thus at the second command apt would
> pull in C(A) or throw an error if it's uninstallable.
>
> If A is installed, B gains Depends:C(A).
> If B is installed, A effectively gains Depends:C(A).
> If you try to install A and B in one go, C(A) will go in as well.
> If you try to uninstall C(A), either A or B has to be uninstalled.
>
> The semantics are pretty obvious to me, it's the number of corner cases and
> complexity that this brings what stops dpkg/apt/aptitude/100-other-tools
> maintainers from implementing that.
>
Propositional logic doesn't have too many corner cases. The problem is simply
that people don't even get current Depends right, introducing additional
expressiveness will worsen the situation.
>
> (Let's rename "C(A)" to "C" for now, the former name makes no sense except
> when talking about dkms.)
>
> Logically, what you want is: !(A & B & !C)
>
> This is: C | !A | !B
>
Correct NNF rewrite, but the first expression is wrong already. Sort of confirms
my above statement. All you say with this is expression is one case you don't
want to occur (it's the "If you try to install A and B in one go, C(A) will go
in as well." case). It would, however, be satisfied by installing C only, or B
and C for that matter.
> Technically, you could already get this effect by introducing a dummy
> package no-B that "Breaks: B" and having A "Depend: C | no-B".
>
> In the case of dkms, there's one dkms and many kernels so B=dkms, A=kernels.
> Too bad, linux-image-$FOO depending on linux-headers-$FOO|no-dkms would be
> too ugly to live. Just think of confusing messages from apt...
>
> This could be done by no-B being a new kind of a virtual package, but I for
> one don't volunteer to code that.
>
I'm still wondering why people are so hesitant to write proper Depends: lines.
I'll reply to Harri's email to reiterate that.
Best,
Michael
08-24-2011, 12:31 PM
Michael Tautschnig
combined dependencies?
Hi again,
[...]
>
> B _does_ depend on C(A), if A is installed.
>
So B depends on
( A & C(A) ) | something-else
> > ... time passes ...
> >
> > magic install C(A) ???
> >
> >
> > Isn't all you want a hard dependency of dkms on both the Linux kernel and its header package? It seems that right now this is just a Recommends. Could you maybe elaborate why a proper Depends: is not appropriate in your opinion?
> >
>
> Its not any header package: dkms needs the _appropriate_ header
> package matching the installed kernel package. If
> linux-image-2.6.39-1-amd64 is installed, then dkms needs
> linux-headers-2.6.39-1-amd64. If linux-image-3.0-1-amd64 is
> installed in parallel, then dkms needs linux-headers-3.0-1-amd64,
> too.
>
> Its just an example, anyway.
>
Isn't all you want (with l-i-1 = linux-image-2.6.39-1-amd64, l-h-2 =
linux-headers-3.0-1-amd64, etc.)
Depends: (l-i-1, l-h-1) | (l-i-2, l-h-2) | ...
And yes, that's not allowed. You need to convert that to CNF. Doable, but
results in a blow-up of the expression size. Hence what you want is
Depends: dkms-l-1 | dkms-l-2
with additional (almost empty) packages dkms-l-1 for 2.6.39 and dkms-l-2 for
3.0.1, where
combined dependencies?
