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 05-21-2011, 11:24 AM
Josselin Mouette
 
Default Conditional Recommends

Hi all,

in Debian many packages have a fine granularity, which is a very good
thing. Unfortunately there is a drawback; when you install two programs
A and B that are designed to interact together, often the piece of code
that makes them interact together is in a separate package (A-plugin-B)
that depends on both. When you install A and B, they don’t interact
together and you have to understand you also need A-plugin-B.

Therefore, I’m wondering whether it would be possible to extend the
syntax of Recommends to allow for conditional dependencies. For example,
in this case:
Package: A
Recommends: A-plugin-B {B}
APT would be made to install A-plugin-B by default, but only if B is
installed too. In addition, it would also have to install it while
pulling B if A is already here.

This has numerous use cases in desktop environment packages. It would
also solve the problem of language packs, and you could ensure that when
installing OOo or iceweasel it would also come with the language packs
corresponding to the installed language tasks on your system.

I’m not familiar at all with the APT internals, so I’d appreciate if
knowledgeable people could answer my questions.
* Does it make any sense at all?
* If so, how hard would it be to implement?
* Does it need changes outside APT?
* Do you think it would be useful?
* If not, what could be done for the aforementioned issues?

Cheers,
--
.'`. Josselin Mouette
: :' :
`. `'
`-
 
Old 05-21-2011, 12:08 PM
Sune Vuorela
 
Default Conditional Recommends

On 2011-05-21, Josselin Mouette <joss@debian.org> wrote:
> * Does it make any sense at all?=20
> * Do you think it would be useful?=20

I do think it makes sense and is useful.

> * If not, what could be done for the aforementioned issues?

I have mostly thought about the 'translation pack' issues, and I guess
it needs some sort of relation in the package.
I was thinking in lines of a new field:
Package: konqueror
Translations: kde-l10n-XX
or
Package: konq-plugins
Translations: konq-plugins-l10n

where apt would substitute XX with configured language codes and try to
install that, and apt in the latter case if configured to pull in
translations, pull in that package.

But maybe I like your more generic approach better.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnitfaqp.p7v.nospam@sshway.ssh.pusling.com">http ://lists.debian.org/slrnitfaqp.p7v.nospam@sshway.ssh.pusling.com
 
Old 05-21-2011, 03:56 PM
Carsten Hey
 
Default Conditional Recommends

* Josselin Mouette [2011-05-21 13:24 +0200]:
> Therefore, I’m wondering whether it would be possible to extend the
> syntax of Recommends to allow for conditional dependencies. For example,
> in this case:
> Package: A
> Recommends: A-plugin-B {B}

The following would be more general:

Package: A
Recommends: !B | A-plugin-B


If we have had this syntax a lot earlier, for example "Build-Conflicts:
X" could have been written as "Build-Depends: !X". But we already
invented all those fields and the number of additional use cases for
exclamation marks as negation in package relationship fields seems to be
rather limited.


With above exclamation mark syntax, we could also express "weak
conflicts", e.g.:

Package: X
Recommends: !Y

Apt would remove Y by default if X gets installed, but users could
overwrite this.


Is there any need for such a weak conflict, e.g., to get rid of gcc-4.4
if gcc-4.5 gets installed? Apt's autoremove feature presumably already
handles most of these cases.

If we add conditional recommends and there is a need for weak conflicts,
I think we should choose a syntax that allows us to express both.


Regards
Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110521155628.GA4236@furrball.stateful.de">http://lists.debian.org/20110521155628.GA4236@furrball.stateful.de
 
Old 05-21-2011, 08:41 PM
Ian Jackson
 
Default Conditional Recommends

Josselin Mouette writes ("Conditional Recommends"):
> Therefore, I?m wondering whether it would be possible to extend the
> syntax of Recommends to allow for conditional dependencies. For example,
> in this case:
> Package: A
> Recommends: A-plugin-B {B}
> APT would be made to install A-plugin-B by default, but only if B is
> installed too. In addition, it would also have to install it while
> pulling B if A is already here.

Simpler than this, and simpler than constructions involving negations
(which would be very troublesome for the resolution algorithms), would
be:

Package: A-plugin-B
Depends: A, B
Recommended-When: A, B

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19928.9057.476390.698665@chiark.greenend.org.uk">h ttp://lists.debian.org/19928.9057.476390.698665@chiark.greenend.org.uk
 
Old 05-22-2011, 08:22 AM
"Eugene V. Lyubimkin"
 
Default Conditional Recommends

On 2011-05-21 21:41, Ian Jackson wrote:
> Simpler than this, and simpler than constructions involving negations
> (which would be very troublesome for the resolution algorithms), would
> be:
>
> Package: A-plugin-B
> Depends: A, B
> Recommended-When: A, B

Putting my 'developer of unpopular package manager' on: no, no, pretty
please, no reverse-Recommends. Firstly, one doesn't want to scan all
package database to find all Recommends for the particular package, and
secondly, this is easily abusable by third-package maintainers and even
packages from completely different, non-Debian repositories:

Package: some-package
Depends: gnome
Recommended-When: gnome


And, still wearing the hat, negations are fairly easy to implement. If
we ever go for implementing conditional dependencies, negations are
great and powerful idea, I'd vote for them.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110522082221.GA12888@r500-debian">http://lists.debian.org/20110522082221.GA12888@r500-debian
 
Old 05-22-2011, 09:55 AM
Goswin von Brederlow
 
Default Conditional Recommends

"Eugene V. Lyubimkin" <jackyf@debian.org> writes:

> On 2011-05-21 21:41, Ian Jackson wrote:
>> Simpler than this, and simpler than constructions involving negations
>> (which would be very troublesome for the resolution algorithms), would
>> be:
>>
>> Package: A-plugin-B
>> Depends: A, B
>> Recommended-When: A, B

What does that mean? Is A-plugin-B recommended when A is installed or B
installed? Or only if A and B are installed? I assume the later. How
would I write recommended if (A & B) | (C & D)?

> Putting my 'developer of unpopular package manager' on: no, no, pretty
> please, no reverse-Recommends. Firstly, one doesn't want to scan all
> package database to find all Recommends for the particular package, and
> secondly, this is easily abusable by third-package maintainers and even
> packages from completely different, non-Debian repositories:
>
> Package: some-package
> Depends: gnome
> Recommended-When: gnome
>
>
> And, still wearing the hat, negations are fairly easy to implement. If
> we ever go for implementing conditional dependencies, negations are
> great and powerful idea, I'd vote for them.

Maybe this would be better?

Package: A
Recommends-If: B > C, D & E > F

If B is installed then recommend C. If D and E are installed then
recommend F.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aaefrreq.fsf@frosties.localnet">http://lists.debian.org/87aaefrreq.fsf@frosties.localnet
 
Old 05-22-2011, 10:17 AM
Ove Kven
 
Default Conditional Recommends

Den 21. mai 2011 13:24, skrev Josselin Mouette:
> * Do you think it would be useful?

For the Wine packages, it would certainly be mighty useful.

Except, of course, that multiarch would make such a thing less effective
on amd64, since cross-arch deps are not supported, and so users will
still be able to go "but I installed the [64-bit] jackd and it
auto-installed the [64-bit] libwine-jack, why doesn't jack work in
[32-bit] Wine".

Still, I'd support the idea.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DD8E2AB.6040106@arcticnet.no">http://lists.debian.org/4DD8E2AB.6040106@arcticnet.no
 
Old 05-22-2011, 02:07 PM
Carsten Hey
 
Default Conditional Recommends

* Goswin von Brederlow [2011-05-22 11:55 +0200]:
> "Eugene V. Lyubimkin" <jackyf@debian.org> writes:
>
> > On 2011-05-21 21:41, Ian Jackson wrote:
> >> Simpler than this, and simpler than constructions involving negations
> >> (which would be very troublesome for the resolution algorithms), would
> >> be:
> >>
> >> Package: A-plugin-B
> >> Depends: A, B
> >> Recommended-When: A, B

Our current package relationship fields can be grouped into:

* Depends, Recommends, Suggests, ...:
- satisfied if all clauses are true
- (subset of) conjunctive normal form
- single clauses are allowed to contain logical 'or's, logical 'and's
are not allowed.

* Conflicts, Breaks, ..., Enhances:
- satisfied if any of the clauses is true
- (subset of) disjunctive normal form
- single clauses are not allowed to contain a logical 'or' nor
a logical 'and' (there were some logical 'or's in Lenny, but they
were pointless and wrong)


If we allow logical 'and' in clauses of disjunctive fields and add
a field similar to 'Enhances:', but for reverse recommendations instead,
the above example could be written as:

Package: A-plugin-B
Depends: A, B
Recommended-By: A & B


> What does that mean? Is A-plugin-B recommended when A is installed or B
> installed? Or only if A and B are installed? I assume the later. How
> would I write recommended if (A & B) | (C & D)?

Recommended-By: A & B, C & D


This also would save the need to possibly add the field
'Suggested-When:' and a reverse recommendation field similar to
'Enhances' in future.

To prevent problems with partial upgrades, a logical 'and' should only
be allowed in fields that do not exist in Squeeze. After Wheezy, they
could be allowed in 'Enhances:' too and if there are according use
cases, maybe even in Conflicts or Breaks.


> > Putting my 'developer of unpopular package manager' on: no, no, pretty
> > please, no reverse-Recommends. Firstly, one doesn't want to scan all
> > package database to find all Recommends for the particular package,

'Enhances:', 'Provides', 'Conflicts' and 'Breaks' also require extensive
scanning in the package database.

Anyway, this subthread is all about reverse recommendations, even with
negations you would need to scan the whole repository for implications
in 'Recommends:' fields, or they would neither solve the tdep problem
nor the original problem (see the end of this mail).


> > and secondly, this is easily abusable by third-package maintainers
> > and even packages from completely different, non-Debian
> > repositories:
> >
> > Package: some-package
> > Depends: gnome
> > Recommended-When: gnome

Third-party repositories have root access on your system, see Google's
(past?) packages for things that could be done. Chrome does not abuse
it but only fiddles in your sources.list and crontab because they want
to ensure that you don't browse the internet with a browser full of
security holes (whether this is a good way to do this does not seem to
belong to this thread).

I think all this is a different problem that should be solved in
a different way, for example by a way to tell apt to ask the user before
a new package from a third party is installed or by a tools similar to
NetBSD's systrace that could be used to restrict what third party
packages are allowed to do.


> > And, still wearing the hat, negations are fairly easy to implement. If
> > we ever go for implementing conditional dependencies, negations are
> > great and powerful idea, I'd vote for them.

I agree that negations are fairly easy to implement, given that only
a subset of all possible things doable with negations (e.g., my
implication example) are allowed and if you find a sane algorithm.
Finding such sane algorithms is not that easy, at least not for all of
us and especially not if you don't spend the necessary amount of time on
thinking about it.


> Maybe this would be better?
>
> Package: A
> Recommends-If: B > C, D & E > F
>
> If B is installed then recommend C. If D and E are installed then
> recommend F.

This would _not_ be a reverse recommendation. One problem with forward
recommendations is that adding new translations for a package would
require adapting this package instead of only the translation packages.
I don't think we could handle this in a sane way if we get tdeps for
complete desktop environments (I'm not sure if this is planned).


Regards
Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110522140717.GA25549@furrball.stateful.de">http://lists.debian.org/20110522140717.GA25549@furrball.stateful.de
 
Old 05-22-2011, 03:08 PM
"Eugene V. Lyubimkin"
 
Default Conditional Recommends

On 2011-05-22 16:07, Carsten Hey wrote:
> > > Putting my 'developer of unpopular package manager' on: no, no, pretty
> > > please, no reverse-Recommends. Firstly, one doesn't want to scan all
> > > package database to find all Recommends for the particular package,
>
> 'Enhances:', 'Provides', 'Conflicts' and 'Breaks' also require extensive
> scanning in the package database.

Conflicts and Breaks do not. So, yes, partly true. I personally don't
want one more reverse-field to handle;

> Anyway, this subthread is all about reverse recommendations, even with
> negations you would need to scan the whole repository for implications
> in 'Recommends:' fields, or they would neither solve the tdep problem
> nor the original problem (see the end of this mail).

I did not spot further statements about this in the end of your mail.
So, no, this subthread is not about reverse recommendations, it's about
conditional recommendations. I don't need to rescan the whole repository
to satisfy '!A | B-plugin-A' given I scanned it once for Provides.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110522150855.GA5031@r500-debian">http://lists.debian.org/20110522150855.GA5031@r500-debian
 
Old 05-22-2011, 03:19 PM
"Eugene V. Lyubimkin"
 
Default Conditional Recommends

> > > and secondly, this is easily abusable by third-package maintainers
> > > and even packages from completely different, non-Debian
> > > repositories:
> > >
> > > Package: some-package
> > > Depends: gnome
> > > Recommended-When: gnome
>
> Third-party repositories have root access on your system, see Google's
> (past?) packages for things that could be done. Chrome does not abuse
> it but only fiddles in your sources.list and crontab because they want
> to ensure that you don't browse the internet with a browser full of
> security holes (whether this is a good way to do this does not seem to
> belong to this thread).

No, third-party repositories do not have any access on my system,
packages from third-party repositories do _if_ I have installed them,
and usually, I think, it's a regular user access, not root one, given I
pre-checked package maintainer scripts before the installation.

'Recommended-When' gives them (= packages from any repositories) an
ability to be installed by default accompanying any package they want. A
major difference as for me.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110522151949.GB5031@r500-debian">http://lists.debian.org/20110522151949.GB5031@r500-debian
 

Thread Tools




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

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