Russ Allbery writes:
> Ben Finney 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 maintainer.
True enough. Thanks fo
Ben Finney writes:
> "Joe Smith" 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 crowd-edited,
but whether a package is a metap
"Joe Smith" 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 |
`\ five.”
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 coun
"David Paleino" 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
State: D
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 i
On Wed, Dec 23, 2009 at 1:21 AM, Carsten Hey 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 new one.
--
bye,
p
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 tran
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 wan
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 a
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 meta
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 i
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.
--
. ''
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
>
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 n
On 2009-12-21, Rene Engelhard 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 field
should l
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
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 :)
Wha
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 us
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), w
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
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 *alrea
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
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
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 Recom
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.
[...]
>
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 metapac
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
> > no
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 br
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
> > imp
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 update
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
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, a
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
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, it
Andreas Metzler wrote:
> David Paleino 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, but I
David Paleino 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". Trouble? Conta
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 Depe
Andreas Metzler wrote:
> David Paleino 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 clear
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 d
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, bu
David Paleino 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 mechanism for
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 curren
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
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 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 , Luca Bruno
46 matches
Mail list logo
