FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 08-20-2011, 06:55 AM
Michael Tautschnig
 
Default combined dependencies?

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)
???


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
 
Old 08-20-2011, 06:57 AM
Sven Joachim
 
Default 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¹².

Sven


¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77324
² http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462361


--
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
 
Old 08-20-2011, 11:31 AM
Adam Borowski
 
Default 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!
 
Old 08-20-2011, 03:08 PM
Lars Wirzenius
 
Default 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.)

--
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


--
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
 
Old 08-20-2011, 04:09 PM
"John D. Hendrickson and Sara Darnell"
 
Default 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
 
Old 08-20-2011, 09:55 PM
Harald Dunkel
 
Default 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)

iEYEARECAAYFAk5QLTwACgkQUTlbRTxpHjfV9QCgkmbeutp6/YRKY6c0mp9irZqh
TC4AoIBa6sBYeExw9eZLNgx+/dsg0DBn
=SRKl
-----END PGP SIGNATURE-----


--
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
 
Old 08-21-2011, 03:51 AM
Charles Plessy
 
Default 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.

https://lists.debian.org/1305977099.4715.47.camel@tomoyo

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
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
 
Old 08-21-2011, 03:55 AM
Charles Plessy
 
Default 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
 
Old 08-24-2011, 12:16 PM
Michael Tautschnig
 
Default 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
 
Old 08-24-2011, 12:31 PM
Michael Tautschnig
 
Default 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

Package: dkms-l-1
Depends: l-i-1, l-h-1

Package: dkms-l-2
Depends: l-i-2, l-h-2

Best,
Michael
 

Thread Tools




All times are GMT. The time now is 12:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org