Le 22 déc. 09 à 13:59, Rene Engelhard a écrit :
Hi,
On Mon, Dec 21, 2009 at 05:12:15PM +, Philipp Kern wrote:
You're on your own with these.
I don't think you want to go though A recommends B which depends on C
which depends on D etc. route on servers which should have only
the stuff
David Paleino da...@debian.org wrote in message
news:16193268.79mvg96...@home.hanskalabs.net...
Hello people,
per the DEP process described at http://dep.debian.net/deps/dep0/, this is
the first call for comments on this proposal.
Title: Meta-Package debian/control field
DEP: 6
Joe Smith wrote:
Counter proposal:
New meta-package Boolean field.
Meta-packages would normally have few or no Depends, being almost
completely recommends.
Recommends (perhaps also Depends) of meta-packages are not marked as
automatically installed.
The usefulness of this part of my
Joe Smith unknown_kev_...@hotmail.com writes:
Counter proposal:
New meta-package Boolean field.
Why a new field in the Packages file?
This seems like an ideal use for debtags. No?
--
\ “A child of five could understand this. Fetch me a child of |
`\
Ben Finney ben+deb...@benfinney.id.au writes:
Joe Smith unknown_kev_...@hotmail.com writes:
Counter proposal:
New meta-package Boolean field.
Why a new field in the Packages file?
This seems like an ideal use for debtags. No?
It doesn't to me. The whole point of debtags is that it's
Russ Allbery r...@debian.org writes:
Ben Finney ben+deb...@benfinney.id.au writes:
This seems like an ideal use for debtags. No?
It doesn't to me. The whole point of debtags is that it's
crowd-edited, but whether a package is a metapackage should be under
the direct control of the package
Hi,
On Mon, Dec 21, 2009 at 05:12:15PM +, Philipp Kern wrote:
You're on your own with these.
I don't think you want to go though A recommends B which depends on C
which depends on D etc. route on servers which should have only
the stuff installed you need. Or even on desktops which you want
Besides sane handling of metapackages we should also think about marking
transitional packages in some way.
This would enable higher level tools like apt to mark them as
automatically installed and thus get rid of useless packages if no other
package depends on them. The dependencies of these
On Wed, Dec 23, 2009 at 1:21 AM, Carsten Hey cars...@debian.org wrote:
we should also think about marking transitional packages in some way.
There was recently a proposal which would remove the need for
transitional binary packages at all, apt would simply migrate the old
package name to the
Steve Langasek wrote:
On Sun, Dec 20, 2009 at 09:30:04PM +0100, David Paleino wrote:
Ubuntu defines a special archive section, 'metapackages', which results
in special tagging/handling of the Depends and Recommends of the
package so
that they're not autoremoved if the metapackage is
David Paleino, 2009-12-21 09:13:17 +0100 :
[...]
I mean, meta-packages should *always* have their Recommends installed,
otherwise they have no point in existing.
If it's *always*, then… isn't your proposal pointless? If it's merely
a *should*, then Recommends is a fine solution.
[...]
Roland Mas wrote:
David Paleino, 2009-12-21 09:13:17 +0100 :
[...]
I mean, meta-packages should *always* have their Recommends installed,
otherwise they have no point in existing.
If it's *always*, then… isn't your proposal pointless? If it's merely
a *should*, then Recommends is a
David Paleino wrote:
[..]
So you're suggesting me to also do a wicd task.
In experimental I have wicd depending on wicd-daemon + wicd-curses|wicd-
gtk -- (it's a simple case, where the user might manually choose the
components, but it's good for the sake of exampling).
As explained on IRC,
Steve Langasek wrote:
In this scenario, with Recommends installed by default (the only sane
model), the vast majority of metapackage dependencies are moved from Depends
to Recommends, so you can remove those Recommends manually without forcing
removal of the metapackage; and you can remove the
Steve Langasek wrote:
From what I can tell, the only difference between the two implementations is
compatibility with disabling installation of Recommends by default.
I don't think this is a good rationale for adding yet another package
relationship field. The Recommends field is *already*
On Mon, Dec 21, 2009 at 09:40:37AM +0100, David Paleino wrote:
So you're suggesting me to also do a wicd task.
In experimental I have wicd depending on wicd-daemon + wicd-curses|wicd-
gtk -- (it's a simple case, where the user might manually choose the
components, but it's good for the sake
Steve Langasek wrote:
Those are exactly the correct semantics. It makes no sense to remove the
depends of a metapackage *and leave the metapackage installed* - what
purpose would that serve?
Being able to
# apt-get --purge remove wicd
(thus removing any dependency/recommends/anything),
On Mon, 2009-12-21 at 07:52 -0800, Steve Langasek wrote:
On Mon, Dec 21, 2009 at 09:40:37AM +0100, David Paleino wrote:
So you're suggesting me to also do a wicd task.
In experimental I have wicd depending on wicd-daemon + wicd-curses|wicd-
gtk -- (it's a simple case, where the user might
On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
However, seems like on IRC we reached kind of a consensus on the fact that
metapackages should use Recommends instead of Depends. I plan to do a mass-
bug filing on this issue sooner or later, just need some time to do it :)
What
Rene Engelhard wrote:
On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
However, seems like on IRC we reached kind of a consensus on the fact
that metapackages should use Recommends instead of Depends. I plan to do
a mass- bug filing on this issue sooner or later, just need some
On 2009-12-21, Rene Engelhard r...@debian.org wrote:
Assuming a system has a senseful configuration and has the recommends-install
thing removed?
I am not really sure that you could use this to back up your claims, really.
This declares a strong, but not absolute, dependency. The Recommends
Rene Engelhard writes:
On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
However, seems like on IRC we reached kind of a consensus on the fact
that metapackages should use Recommends instead of Depends. I plan to do
a mass- bug filing on this issue sooner or later, just need
On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
Those are exactly the correct semantics. It makes no sense to remove the
depends of a metapackage *and leave the metapackage installed* - what
purpose would that serve?
Being able to
# apt-get --purge remove wicd
(thus
Steve Langasek wrote:
Or do you really mean that you expect the package manager to treat removal
of 'wicd' differently based on whether the removal is triggered by
'apt-get remove wicd' vs. 'apt-get remove dependency-of-wicd'?
Exactly that, plus the fact that it is a metapackage.
--
. ''`.
David Paleino writes:
Rene Engelhard wrote:
On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
However, seems like on IRC we reached kind of a consensus on the fact
that metapackages should use Recommends instead of Depends. I plan to do
a mass- bug filing on this issue sooner
Thomas Goirand wrote:
Steve Langasek wrote:
In this scenario, with Recommends installed by default (the only sane
model), the vast majority of metapackage dependencies are moved from Depends
to Recommends, so you can remove those Recommends manually without forcing
removal of the metapackage;
Felipe Sateler a écrit :
In this particular case, none. But in the general case there are reasons
to keep the metapackage installed. For example, I want to try out gnome.
So I install the gnome metapackage. I do not want (say) brasero. But I
still want everything removable by just saying
Hello people,
per the DEP process described at http://dep.debian.net/deps/dep0/, this is
the first call for comments on this proposal.
Title: Meta-Package debian/control field
DEP: 6
State: DRAFT
Date: 2009-12-20
Drivers: David Paleino da...@debian.org,
David Paleino wrote:
Hello people,
per the DEP process described at http://dep.debian.net/deps/dep0/, this is
the first call for comments on this proposal.
Title: Meta-Package debian/control field
DEP: 6
[..]
Here's the full text, for your convenience:
Introduction
Hello,
David Paleino wrote:
Implementation
[...]
### Package managers ###
[...]
If any dependant package is a meta-package, as defined by this
document, it should **NOT** be removed, opposed to what the current
implementations do. The package manager should then add the removed
package to a
Eugene V. Lyubimkin wrote:
Hello,
Hello Eugene,
thanks for your feedback.
David Paleino wrote:
Implementation
[...]
### Package managers ###
[...]
If any dependant package is a meta-package, as defined by this
document, it should **NOT** be removed, opposed to what the current
David Paleino da...@debian.org wrote:
[...]
With the *autoremove* command being now widely used, it can become
difficult for a user to install a meta-package but some packages it
depends on.
I do not understand this, is there a word missing?
[...]
This document thus tries to introduce a new
David Paleino wrote:
Eugene V. Lyubimkin wrote:
No, it doesn't. Dpkg and any sane high-level package manager won't
consider installing/upgrading/keeping some package (meta or not) without
all Depends installed.
We can always change our tools to comply with that, no? :)
Well, yes, but I
Eugene V. Lyubimkin writes:
Hello,
David Paleino wrote:
Implementation
[...]
### Package managers ###
[...]
If any dependant package is a meta-package, as defined by this
document, it should **NOT** be removed, opposed to what the current
implementations do. The package
Andreas Metzler wrote:
David Paleino da...@debian.org wrote:
[...]
With the *autoremove* command being now widely used, it can become
difficult for a user to install a meta-package but some packages it
depends on.
I do not understand this, is there a word missing?
Probably I didn't use a
George Danchev wrote:
Eugene V. Lyubimkin writes:
No, it doesn't. Dpkg and any sane high-level package manager won't
consider installing/upgrading/keeping some package (meta or not) without
all Depends installed.
I agree. That flies directly in the face of Policy definition of Depends:
David Paleino da...@debian.org wrote:
Andreas Metzler wrote:
[...]
I hope no-one ever depends on a meta-package.
Do you have any real case for this?
[...]
kde depends on kde-core.
cu andreas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe.
Andreas Metzler wrote:
David Paleino da...@debian.org wrote:
Andreas Metzler wrote:
[...]
I hope no-one ever depends on a meta-package.
Do you have any real case for this?
[...]
kde depends on kde-core.
And both are metapackages.
(apart from the fact that I can't find kde nor kde-core,
I agree with Eugene: the spec as presented is flawed. All package
management tools (you forgot to list dpkg) treat Depends-satisfaction
as an invariant, and there isn't really a compelling reason for this
to change. The wording you present is a little confusing, but once
you work through it,
Daniel Burrows wrote:
[..]
I actually would prefer a Meta-Depends sort of solution. The
dependencies we're talking about are really not package dependencies
in the normal sense at all, and we shouldn't be confusing them with
normal dependencies. IMO, that basic conflation, while a
On Sun, Dec 20, 2009 at 05:06:39PM +0100, David Paleino wrote:
In fact, when removing any dependency of the meta-package, it gets
removed as well, and all other dependencies become *leaf packages* that
autoremove will try to remove from the system. This is usually not
what the users want, as
Steve Langasek wrote:
On Sun, Dec 20, 2009 at 05:06:39PM +0100, David Paleino wrote:
In fact, when removing any dependency of the meta-package, it gets
removed as well, and all other dependencies become *leaf packages* that
autoremove will try to remove from the system. This is usually not
Hi David,
thanks for taking the initiative of improving the management of meta-packages.
As you see now, it is a big project !
Like any major change in the package management system, the safest solution to
the problem is patience: implement the solution in given release, let the users
have
On Sun, Dec 20, 2009 at 09:30:04PM +0100, David Paleino wrote:
Ubuntu defines a special archive section, 'metapackages', which results in
special tagging/handling of the Depends and Recommends of the package so
that they're not autoremoved if the metapackage is removed. This is
On Sun, Dec 20, 2009 at 06:11:46PM +0100, Andreas Metzler wrote:
The current proposal is not backwards compatible since it fundamentally
changes the meaning of Depends. Depends is transitive. If A depends on
B, and B depends on C. A can rely on functionality proveided by C.
Your proposal
On Sun, 20 Dec 2009, David Paleino wrote:
Daniel Burrows wrote:
[..]
I actually would prefer a Meta-Depends sort of solution. The
dependencies we're talking about are really not package dependencies
in the normal sense at all, and we shouldn't be confusing them with
normal
46 matches
Mail list logo
