Bug#678815: ITP: wmfs -- Window Manager From Scratch

[Mickaël Raybaud-Roig]

Package: wnpp
Severity: wishlist
Owner: "Mickaël Raybaud-Roig" <raybau...@gmail.com>

* Package name : wmfs
Version : 2~beta201206
Upstream Author : Martin Duquesnoy <xor...@gmail.com>
* URL : http://wmfs.info
* License : BSD
Programming Lang: C
Description : Window Manager From Scratch



« WMFS2 is a lightweight and highly configurable tiling window manager for
X written in C. wmfs2 is a free software distributed under the BSD
license. it can be drive from keyboard or mouse and it's configuration
stands in one text file easily understandable »



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Thomas Koch]

Mickaël Raybaud-Roig:

> Package: wnpp
> Severity: wishlist
> Owner: "Mickaël Raybaud-Roig" <raybau...@gmail.com>
>
> * Package name : wmfs
> Version : 2~beta201206
> Upstream Author : Martin Duquesnoy <xor...@gmail.com>
> * URL : http://wmfs.info
> * License : BSD
> Programming Lang: C
> Description : Window Manager From Scratch
>
>
>
> « WMFS2 is a lightweight and highly configurable tiling window manager for
> X written in C. wmfs2 is a free software distributed under the BSD
> license. it can be drive from keyboard or mouse and it's configuration
> stands in one text file easily understandable »

Hi,

I shortened the list to only include one line for each window manager already
in Debian:

axi-cache --all search x11::window-manager
100% 9wm - emulation of the Plan 9 window manager 8-1/2
100% aewm - minimalist window manager for X11
100% aewm++ - minimal window manager written in C++
100% afterstep - window manager with the NEXTSTEP look and feel
100% blackbox - Window manager for X
100% bluetile - full-featured tiling for the GNOME desktop environment
100% dwm - dynamic window manager
100% evilwm - a minimalist window manager for X11
100% fluxbox - Highly configurable and low resource X11 Window manager
100% flwm - Fast Light Window Manager
100% fvwm - F(?) Virtual Window Manager
100% i3-wm - improved dynamic tiling window manager
100% icewm - wonderful Win95-OS/2-Motif-like window manager
100% jwm - very small lightweight pure X11 window manager with tray and menus
100% kde-window-manager - K window manager (KWin)
100% larswm - Lars Window Manager with tiled windows
100% lwm - lightweight window manager
100% matchbox-window-manager - window manager for resource-limited systems
100% metacity - lightweight GTK+ window manager
100% miwm - minimalist window manager with virtual workspaces
100% mutter - lightweight GTK+ window manager
100% openbox - standards compliant, fast, light-weight, extensible window
manager
100% oroborus - A lightweight themeable windowmanager for X
100% pekwm - very light window manager
100% ratpoison - keyboard-only window manager
100% sapphire - A minimal but configurable X11R6 window manager
100% stumpwm - tiling, keyboard driven Common Lisp window manager
100% tinywm - tiny window manager
100% twm - Tab window manager
100% vtwm - Virtual Tab Window Manager
100% w9wm - enhanced window manager based on 9wm
100% windowlab - small and simple Amiga-like window manager
100% wm2 - small, unconfigurable window manager
100% wmaker - NeXTSTEP-like window manager for X
100% wmii - lightweight tabbed and tiled X11 window manager, version 3
100% xfwm4 - window manager of the Xfce project
100% xmonad - Lightweight X11 window manager written in Haskell
100% e17 - Enlightenment DR17 Window Manager
100% olvwm - OpenLook virtual window manager
100% olwm - Open Look Window Manager
100% herbstluftwm - manual tiling window manager for X11

Thomas Koch, http://www.koch.ro


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/201206241722...@koch.ro

[Mickaël Raybaud-Roig]

Hi,

You're right, there are already a lot of X11 window managers in Debian ...

But WMFS is not already in the list and it works fine, that's why I want to package it :-)

PS: i've uploaded a package here: http://mentors.debian.net/package/wmfs

--
Mickaël Raybaud-Roig <raybau...@gmail.com>

[Neil Williams]

> You're right, there are already a lot of X11 window managers in Debian ...
>
> But WMFS is not already in the list and it works fine, that's why I want to package it :-)

That is no reason for it to be in Debian.

Debian is not a dumping ground for every piece of free software just
because it "works fine".

Do the hard work of objectively identifying *all* of the pros and cons
of *all* the existing equivalents inside Debian already, compare those
with the pros and cons of yours and if there's any time left before
the heat death of the universe, maybe it can be considered.

> PS: i've uploaded a package here: http://mentors.debian.net/package/wmfs

That is no reason for it to be uploaded either.

There is no good reason for any new window managers in Debian. There
are good reasons to look at removing at least 10% of the ones which are
in Debian.

Doing that comparative analysis would be a good start for identifying
which can be removed - now *that* would be doing something useful for
Debian. This bug is *not* useful to anyone. Please close it and find an
RC bug to close instead.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Arno Töll]

On 24.06.2012 19:15, Neil Williams wrote:
> This bug is *not* useful to anyone. Please close it and find an
> RC bug to close instead.

I'm pretty sure this could be expressed in another tone. Especially
since we welcome everyone (you know) and we have _no_ written rule what
belongs into Debian and what not, and nobody who decides on that beyond
legal issues.

How would Mickaël know, then?


--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

[Neil Williams]

On Sun, 24 Jun 2012 19:31:12 +0200
Arno Töll <ar...@debian.org> wrote:

Dropping the bug CC.

> On 24.06.2012 19:15, Neil Williams wrote:
> > This bug is *not* useful to anyone. Please close it and find an
> > RC bug to close instead.
>
> I'm pretty sure this could be expressed in another tone. Especially
> since we welcome everyone (you know) and we have _no_ written rule what
> belongs into Debian and what not, and nobody who decides on that beyond
> legal issues.

This isn't about welcoming people, this is about keeping pointless
vanity packages out of the archive. We don't need absolute rules on
this but the whole point of ITP bugs being CC'd to this list is so that
people on this list get a chance to head off mistakes. Adding another
pointless alternative for packages which are already duplicated over
and over *is* a mistake.

Maybe the Developer Reference should be strengthened to require a check
against the existing archive as well as the WNPP list but, IMHO, that's
a bit of common sense which all maintainers and prospective maintainers
should be able to demonstrate. If you feel that's not common, feel free
to file a bug against the Developer Reference.

Whatever happens, there is no place for yet another duplicate of
packages which already have multiple duplicates in the archive.

There isn't even any point waiting for such packages to get RC bugs to
be able to remove them. Stop them getting in in the first place.

[Wookey]

+++ Neil Williams [2012-06-24 18:51 +0100]:

> On Sun, 24 Jun 2012 19:31:12 +0200
> Arno Töll <ar...@debian.org> wrote:
>
> Dropping the bug CC.
>
> > On 24.06.2012 19:15, Neil Williams wrote:
> > > This bug is *not* useful to anyone. Please close it and find an
> > > RC bug to close instead.
> >
> > I'm pretty sure this could be expressed in another tone. Especially
> > since we welcome everyone (you know) and we have _no_ written rule what
> > belongs into Debian and what not, and nobody who decides on that beyond
> > legal issues.
>
> This isn't about welcoming people, this is about keeping pointless
> vanity packages out of the archive.

Arno's point was that if you were clever you could do both.

It's possible to tell someone that packaing this particular thing is a
bad idea without being rude and superiour. If one does that they might
go away with the impression that Debian is a civilised place where
they'd like to help out, rather than a place full of people who are
usually right but arrogant with it.

Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120624183...@stoneboat.aleph1.co.uk

[Philip Ashmore]

I didn't know you could do that with axi-cache - thanks. I'm always on
the lookout for a better window manager - it's a matter of taste.

Bug#678854: Acknowledgement (icewm won't start)

Philip

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FE75DA9...@philipashmore.com

[Arno Töll]

Hi,

On 24.06.2012 19:51, Neil Williams wrote:
> Whatever happens, there is no place for yet another duplicate of
> packages which already have multiple duplicates in the archive.

Letting alone the package in particular (I don't even know it, nor do I
care), I wonder where you'd draw that line. As you say yourself: There
are lots of alternative packages in the archive already. So, what makes
all the other alternatives acceptable but this one not?

What makes 42 window manager acceptable but not 43?

> There isn't even any point waiting for such packages to get RC bugs to
> be able to remove them. Stop them getting in in the first place.

I'm not in favor to get yet another window manager in Debian. All I'm
saying is that filing a WNPP bug and wait whether a people complain loud
enough is not the way to learn that. Especially since a WNPP bug
complaints are not worth that much. If you happen to find a DD to upload
your stuff or you are DD yourself, you can silently ignore any comments
if you like and upload nonetheless.

That's how we end up with 42 display manager. Complaining on the 43th is
not the way to go.


Moreover, would you be a well respected Debian Developer today if your
replies to your first WNPP bug (if you filed any, I don't know) back
then told you to go away, nobody appreciates your work?

[Bart Martens]

Hi Neil,

I agree with Arno about the tone.

I don't have a strong opinion on whether this package in particular should be
kept out of Debian. You may be right about this package in particular, no
idea.

About allowing new packages in Debian in general : On the one hand you have a
point that Debian should not collect any free software, but on the other hand I
think that it is OK to have multiple implementations of the same/similar
functionality in Debian, and over time the popcon stats may indicate that a
newer package wins over an older package. It is, in my opinion, not always
possible to judge the potential of a package before it has been in Debian for
some time. Having competing alternatives in Debian is OK, even good, in my
opinion.

Regards,

Bart Martens

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120624184...@master.debian.org

[Vincent Bernat]

❦ 24 juin 2012 19:15 CEST, Neil Williams <code...@debian.org> :

>> > I shortened the list to only include one line for each window manager already
>> > in Debian:

[...]

I think the list is incomplete. For example, awesome is not in it but is
properly tagged.

>> You're right, there are already a lot of X11 window managers in Debian ...
>>
>> But WMFS is not already in the list and it works fine, that's why I want to package it :-)
>
> That is no reason for it to be in Debian.
>
> Debian is not a dumping ground for every piece of free software just
> because it "works fine".

A window manager is something highly personal (like an editor). You put
a lot of effort to configure it and to get used to it. If Debian didn't
had my favorite window manager, I would be quite unhappy to have to
learn one which was here before. Plus, I would need to rewamp my whole
configuration.
--
printk("??? No FDIV bug? Lucky you...\n");
2.2.16 /usr/src/linux/include/asm-i386/bugs.h

[Neil Williams]

On Sun, 24 Jun 2012 20:42:33 +0200
Arno Töll <ar...@debian.org> wrote:

> On 24.06.2012 19:51, Neil Williams wrote:
> > Whatever happens, there is no place for yet another duplicate of
> > packages which already have multiple duplicates in the archive.
>
> Letting alone the package in particular (I don't even know it, nor do I
> care)

(Neither do I, particularly - but Thomas' list made it just too
obvious that there was no justification for the bug report at the time
of filing.)

>, I wonder where you'd draw that line. As you say yourself: There
> are lots of alternative packages in the archive already. So, what makes
> all the other alternatives acceptable but this one not?
>
> What makes 42 window manager acceptable but not 43?

If it can be justified. That's what the objective comparison would need
to demonstrate. That's an established pattern in Debian - if someone
wants to add something which is the same as something else, there
should be a good reason to introduce the new one in that it needs to be
better than the existing ones in some way which isn't achievable just
by patching one of the existing ones.

Debian works on merit - packages and maintainers. Suggesting or
packaging something which is without merit will usually result in
complaints from your peers. Cope with it. Maintainers should not expect
to be treated with kid gloves when what they are actually doing is
wasting the free time of other volunteers.

We're used to 'Justification' as a concept for RC bugs, well an ITP is
a bug in Debian and can also require justification. Some ITP bugs are
simply invalid.

Someone needs to make that call and as we're all part of the QA team,
various people do it according to their own free time, work area,
expertise and general levels of annoyance with daft ideas.

Whether it's a joke package or a tiny package which needs to go into a
collective package (goodies or devscripts or whatever), if maintainers
(prospective or existing) can't do their own research ahead of filing a
bug, it is up to the rest of us to point out the error.

> I'm not in favor to get yet another window manager in Debian. All I'm
> saying is that filing a WNPP bug and wait whether a people complain loud
> enough is not the way to learn that.

So feel free to file a patch to the Developer Reference explaining that
if maintainers of prospective packages don't check for existing packages
which provide the same or very similar functionality, any request to
package such a duplicate needs to be accompanied by a detailed
reasoning of *why* the existing packages are sufficiently inadequate
that a new package is warranted instead of patching what we have.

To me, such an expectation is common sense and I'm quite happy to
continue criticising ITP's on the basis of being an unjustifiable
duplicate of existing packages.

> Especially since a WNPP bug
> complaints are not worth that much. If you happen to find a DD to upload
> your stuff or you are DD yourself, you can silently ignore any comments
> if you like and upload nonetheless.

At which point, the credibility of any such DD is diminished, as is
the credibility of any DD who sponsors such packages despite
complaints from his/her peers.

> That's how we end up with 42 display manager. Complaining on the 43th is
> not the way to go.

The 43rd must be *justified* - there needs to be a reason why the lack
of this package is a bug in Debian. Otherwise the request could just as
well be reassigned as a wishlist bug against one of the alternatives.

> Moreover, would you be a well respected Debian Developer today if your
> replies to your first WNPP bug (if you filed any, I don't know) back
> then told you to go away, nobody appreciates your work?

As hinted in my previous post, I did my research before filing my first
(and subsequent) ITP bugs. Nobody disagreed at the time and I have
since removed the first package I introduced into Debian as it's time
had passed. There were no duplicates but there was also no
justification for it remaining in the archive for wheezy.

An ITP is meant to be a bug in Debian - that Debian is missing some
functionality. It is perfectly acceptable to require that such
functionality can be implemented in a different way by working with a
package we already have. Triaging bugs requires that the bugs are
tested for validity before spending more time on the fix. No point
putting the wrong fix into the archive.

However, I also had comments from other bugs once becoming a DD which
showed where I'd gone wrong on those packages, but that just meant that
I had to show I could accept criticism and just get on with fixing
stuff. Those who did criticise me I now count as friends, so that is
how I think Debian should work.

[Neil Williams]

On Sun, 24 Jun 2012 18:45:54 +0000
Bart Martens <ba...@debian.org> wrote:

> About allowing new packages in Debian in general : On the one hand you have a
> point that Debian should not collect any free software, but on the other hand I
> think that it is OK to have multiple implementations of the same/similar
> functionality in Debian, and over time the popcon stats may indicate that a
> newer package wins over an older package. It is, in my opinion, not always
> possible to judge the potential of a package before it has been in Debian for
> some time. Having competing alternatives in Debian is OK, even good, in my
> opinion.

The maintainer has to make that judgement, it's just one of the things
maintainers have to do. popcon is no indicator here, it is about
whether there is a bug in Debian, independent of this package. I apply
the same criteria to all my packages and I have and will continue to
remove any which do not merit a place in a stable release.

What *quality* issue is meant to being fixed by a new package? If
there's none, then the ITP is invalid and the package is without merit.
Just like any other bug - if the submitter has just got it wrong (for
whatever reason), the bug can be deemed invalid. Sometimes an
improvement to the documentation can help others not make the same
error, sometimes the docs are fine and it's just a mistake.

Multiple implementations hurt the archive, waste ftpmaster time, waste
QA time, waste wanna-build time, waste Debian resources, complicate
transitions and often collect RC bugs. In short, the more duplicates
there are, the higher the percentage of those duplicates which will
go to rot in the archive, causing aggravation for everyone.

Competition is useful, surfeit is harmful.

If a new package does have merit compared to all the existing
equivalents, then explain those merits and let your peers judge the
package.

The issue is to fix the problem in Debian, not just introduce a new
package which fixes nothing.

[Josselin Mouette]

Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit :
> What makes 42 window manager acceptable but not 43?

Who said 42 is acceptable?

--
.''`. Josselin Mouette
: :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1340569299.29283.0.camel@tomoyo

[Bart Martens]

On Sun, Jun 24, 2012 at 08:48:48PM +0100, Neil Williams wrote:
> On Sun, 24 Jun 2012 18:45:54 +0000
> Bart Martens <ba...@debian.org> wrote:
>
> > About allowing new packages in Debian in general : On the one hand you have a
> > point that Debian should not collect any free software, but on the other hand I
> > think that it is OK to have multiple implementations of the same/similar
> > functionality in Debian, and over time the popcon stats may indicate that a
> > newer package wins over an older package. It is, in my opinion, not always
> > possible to judge the potential of a package before it has been in Debian for
> > some time. Having competing alternatives in Debian is OK, even good, in my
> > opinion.
>
> The maintainer has to make that judgement, it's just one of the things
> maintainers have to do. popcon is no indicator here, it is about
> whether there is a bug in Debian, independent of this package.

Not only the maintainer but also the many users judge how useful a package is
in Debian. This judgement cannot always be made at ITP time. Popcon does
indicate how popular the package is, doesn't it ?

> I apply
> the same criteria to all my packages and I have and will continue to
> remove any which do not merit a place in a stable release.

I see no problem with removing packages that don't belong in a Debian stable
release. But weren't we talking about judging at ITP time on whether the
package is allowed to enter Debian ?

>
> What *quality* issue is meant to being fixed by a new package? If
> there's none, then the ITP is invalid and the package is without merit.
> Just like any other bug - if the submitter has just got it wrong (for
> whatever reason), the bug can be deemed invalid. Sometimes an
> improvement to the documentation can help others not make the same
> error, sometimes the docs are fine and it's just a mistake.

I don't think that an ITP is only valid if it fixes something in Debian.
Sometimes a package is worth entering Debian simply because it is good free
software, regardless of any alternatives already in Debian.

>
> Multiple implementations hurt the archive, waste ftpmaster time, waste
> QA time, waste wanna-build time, waste Debian resources, complicate
> transitions and often collect RC bugs. In short, the more duplicates
> there are, the higher the percentage of those duplicates which will
> go to rot in the archive, causing aggravation for everyone.

I'm not convinced that the above applies to "multiple implementations" more
than to simply "many packages". Neglected packages about should be removed.
That applies to any package in Debian, not only to "multiple implementations".

>
> Competition is useful, surfeit is harmful.
>
> If a new package does have merit compared to all the existing
> equivalents, then explain those merits and let your peers judge the
> package.

If there are sufficient volunteers who want to spend their time on packaging
the software and maintaining it in Debian, then why not let the users judge the
package ?

>
> The issue is to fix the problem in Debian, not just introduce a new
> package which fixes nothing.

The issue is to allow new packages a chance in Debian to rise above the
existing alternatives in Debian. This cannot always be judged at ITP time.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120624204...@master.debian.org

[Bart Martens]

On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote:
> Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit :
> > What makes 42 window manager acceptable but not 43?
>
> Who said 42 is acceptable?

The neglected ones should be removed. If they're all well maintained and all
used, then 43 is acceptable, in my opinion.

Regards,

Bart Martens

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120624204...@master.debian.org

[Neil Williams]

On Sun, 24 Jun 2012 20:48:43 +0000
Bart Martens <ba...@debian.org> wrote:

> On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote:
> > Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit :
> > > What makes 42 window manager acceptable but not 43?
> >
> > Who said 42 is acceptable?
>
> The neglected ones should be removed. If they're all well maintained and all
> used, then 43 is acceptable, in my opinion.

There is general agreement that neglected ones should be removed, it
just comes down to someone doing the work and making that assessment. If
you're interested, file the RM bugs in time for wheezy.

Feel free to re-use a similar measure/approximation for "neglect" as I
blogged about for the measure/approximation of "rubbish". (Linked from
my homepage below.)

With any objective analysis of the current 42, I find it impossible to
believe that all 42 would re-qualify.

Of course, someone who wanted to introduce #43 may be the person in
the right place to do the analysis.

It isn't a small task - if it doesn't get done for wheezy it's not that
bad but it does seem justified before #43 arrives. I'd expect that the
process itself shows that #43 isn't actually needed at all and that
whatever is desired can be achieved by patching one of the existing
ones.

[Neil Williams]

On Sun, 24 Jun 2012 20:46:55 +0000
Bart Martens <ba...@debian.org> wrote:

> > The maintainer has to make that judgement, it's just one of the things
> > maintainers have to do. popcon is no indicator here, it is about
> > whether there is a bug in Debian, independent of this package.
>
> Not only the maintainer but also the many users judge how useful a package is
> in Debian. This judgement cannot always be made at ITP time. Popcon does
> indicate how popular the package is, doesn't it ?

Popcon indicates almost nothing - least of all popularity. The
weaknesses of popcon for archive-related questions is well documented.
It might give a hint but it is *not* a reliable indicator.

99% of the Debian machines I install have no means of communicating via
popcon - ever. What's installed on those is completely invisible.

> > I apply
> > the same criteria to all my packages and I have and will continue to
> > remove any which do not merit a place in a stable release.
>
> I see no problem with removing packages that don't belong in a Debian stable
> release. But weren't we talking about judging at ITP time on whether the
> package is allowed to enter Debian ?

Yes. An ITP is a bug in Debian and bugs need to be triaged - triage
involves assessing whether the bug is valid. Before trying to fix the
problem, identify that the problem is the problem you think it is.

That kind of response makes me think that you haven't tried to remove a
set of packages and have no idea how difficult it can be.

> > What *quality* issue is meant to being fixed by a new package? If
> > there's none, then the ITP is invalid and the package is without merit.
> > Just like any other bug - if the submitter has just got it wrong (for
> > whatever reason), the bug can be deemed invalid. Sometimes an
> > improvement to the documentation can help others not make the same
> > error, sometimes the docs are fine and it's just a mistake.
>
> I don't think that an ITP is only valid if it fixes something in Debian.
> Sometimes a package is worth entering Debian simply because it is good free
> software, regardless of any alternatives already in Debian.

Rubbish. Complete tosh. That is precisely the attitude that leads to
Debian being seen as a dumping ground for vanity packages and other
trash.

An ITP is a statement that there is some *functionality* absent in
Debian. Someone cannot do something because the existing packages don't
provide that functionality - that is a justification for a new package
but it can also be justification for a patch to an existing package.
Copying ITP bugs to this list is one of the ways of spotting when that
can be done instead of adding another package.

If I file a bug against one of your packages that it needs to do
something which would be a complete waste of your time, do you not
have the right and obligation to tell me to not be so stupid and to
close the bug as invalid? Well, WNPP is one of your packages just as it
is one of mine because it comes under the QA team.

> > Multiple implementations hurt the archive, waste ftpmaster time, waste
> > QA time, waste wanna-build time, waste Debian resources, complicate
> > transitions and often collect RC bugs. In short, the more duplicates
> > there are, the higher the percentage of those duplicates which will
> > go to rot in the archive, causing aggravation for everyone.
>
> I'm not convinced that the above applies to "multiple implementations" more
> than to simply "many packages". Neglected packages about should be removed.
> That applies to any package in Debian, not only to "multiple implementations".

Yes, so do both. There are still plenty of packages which could
justifiably be removed before Wheezy is released.

> > Competition is useful, surfeit is harmful.
> >
> > If a new package does have merit compared to all the existing
> > equivalents, then explain those merits and let your peers judge the
> > package.
>
> If there are sufficient volunteers who want to spend their time on packaging
> the software and maintaining it in Debian, then why not let the users judge the
> package ?

There never *ARE* enough volunteers. Even if there are today, there is
no guarantee that there will be by the time of the next release and
when volunteers give up, they tend not to have time to tidy up after
themselves by removing packages.

Why do you think we have so many RC bugs? We never have enough
volunteers - if we did, we could have frozen at the start of June and
we would make the release on the last day of DebConf.

As it is, we have over 670 RC bugs right now and we only have one Gregor
Herrmann.

> > The issue is to fix the problem in Debian, not just introduce a new
> > package which fixes nothing.
>
> The issue is to allow new packages a chance in Debian to rise above the
> existing alternatives in Debian. This cannot always be judged at ITP time.

On what basis are things going to "rise above" if there is nothing which
separates them from the existing packages?

NotInventedHere syndrome should *not* be welcome in Debian. That's not
progress, that's just abusing the contributions of your peers.

Don't make more work for people.

[Adam Borowski]

On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote:

> Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit :
> > What makes 42 window manager acceptable but not 43?
>
> Who said 42 is acceptable?

Sure, let's start removals with ones that hard-depend on things a window
manager shouldn't touch, like network-manager. If one has to choose
between working networking and a given window manager, the choice is obvious
-- except maybe for newbie users, who won't understand what to do when they
get hard-stumped faced with a basic task like connecting a phone via USB[1],
or for less newbie ones, any bridged or multi-homed setup.

So, a good deal of smaller window managers are functionally redundant and
could be culled, but they at least don't break unrelated packages. Whether
one prefers Gnome3 interface or something more traditional[2] is one thing,
but there are technical downsides for Gnome that could be trivially fixed.
And yet are not.


[1]. With non-ancient udev, connecting one spawns an "usb0" interface you can
configure any usual way, unless you have n-m continuously screwing with it.

[2]. Let's not go into flamewars about user interface here, it has been
overdone already.

--
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120624215...@angband.pl

[Josselin Mouette]

Oooh, NM bashing. I like completely irrelevant NM bashing that suddenly
pops in an unrelated discussion. It’s been some time.

Reading NM bashing really makes me want to jump on my packages and
cripple their functionality so that they work with inferior networking
scripts.

kthxbye,

--
.''`. Josselin Mouette
: :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1340576086.29283.16.camel@tomoyo

[Adam Borowski]

On Mon, Jun 25, 2012 at 12:14:46AM +0200, Josselin Mouette wrote:
> Oooh, NM bashing. I like completely irrelevant NM bashing that suddenly
> pops in an unrelated discussion. It’s been some time.
>
> Reading NM bashing really makes me want to jump on my packages and
> cripple their functionality so that they work with inferior networking
> scripts.

Stress on "so that they work".

Unless NM ever gets parity with ifupdown, or at least can be reasonably
disabled, a hard-dependency makes a window manager outright useless, for
technical rather than UI preference reasons.

Debian has "recommends" specifically for such cases.

--
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120624222...@angband.pl

[Miles Bader]

Arno Töll <ar...@debian.org> writes:
> On 24.06.2012 19:15, Neil Williams wrote:
>> This bug is *not* useful to anyone. Please close it and find an
>> RC bug to close instead.
>
> I'm pretty sure this could be expressed in another tone. Especially
> since we welcome everyone (you know) and we have _no_ written rule
> what belongs into Debian and what not, and nobody who decides on
> that beyond legal issues.

OTOH, drama-queen whining about new packages is absolutely _classic_
Debian...

-miles

--
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours. [Greenpeace advertisement, New York Times, 25 February 1990]

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87ipeg7...@catnip.gol.com

[Bart Martens]

On Sun, Jun 24, 2012 at 10:18:00PM +0100, Neil Williams wrote:
> On Sun, 24 Jun 2012 20:48:43 +0000
> Bart Martens <ba...@debian.org> wrote:
>
> > On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote:
> > > Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit :
> > > > What makes 42 window manager acceptable but not 43?
> > >
> > > Who said 42 is acceptable?
> >
> > The neglected ones should be removed. If they're all well maintained and all
> > used, then 43 is acceptable, in my opinion.
>
> There is general agreement that neglected ones should be removed, it
> just comes down to someone doing the work and making that assessment.

True.

> If
> you're interested, file the RM bugs in time for wheezy.

You question those 42 implementations, so you can analyse them, file RM bugs
where appropriate, and write a justification for rejecting #43.

>
> Feel free to re-use a similar measure/approximation for "neglect" as I
> blogged about for the measure/approximation of "rubbish". (Linked from
> my homepage below.)

If that text reflects consensus, then feel free to make
http://qa.debian.org/howto-remove.html point to that text.

>
> With any objective analysis of the current 42, I find it impossible to
> believe that all 42 would re-qualify.

Good, you seem to have already started with analysing those 42 implementations.

>
> Of course, someone who wanted to introduce #43 may be the person in
> the right place to do the analysis.

This person "may be in the right place to do the analysis", but I don't think
that this person must do that analysis.

>
> It isn't a small task - if it doesn't get done for wheezy it's not that
> bad but

The coming freeze period may be a good time for spending time on removals by
anyone interested.

> it does seem justified before #43 arrives.

It is not bad/wrong that you want that analysis to be done now.

> I'd expect that the
> process itself shows that #43 isn't actually needed at all and that
> whatever is desired can be achieved by patching one of the existing
> ones.

Yes, the analysis may result in the conclusion that #43 is not needed in
Debian. But please don't reject #43 just because nobody (not you, not the ITP
submitter, not any volunteer) has compared it with the 42 other
implementations.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120625062...@master.debian.org

[Antti-Juhani Kaijanaho]

Adam Borowski <kilo...@angband.pl> kirjoitti:

>Sure, let's start removals with ones that hard-depend on things a
>window
>manager shouldn't touch, like network-manager.

Which wm does that? I know it isn't gnome-shell at least, as I've been
using it quite successfully without nm installed.

(I hope this message looks okay - I'm sending from an unfamiliar
MUA.)
--
Antti-Juhani

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1eb44713-6893-4e9d...@email.android.com

[Russ Allbery]

Neil Williams <code...@debian.org> writes:

> Whatever happens, there is no place for yet another duplicate of
> packages which already have multiple duplicates in the archive.

I think it's hard to defend the contention that the quantity of packages
has some strong relationship to whether or not those programs duplicate
the functionality of other programs. Surely it also depends on the type
of program, rather heavily.

For example, I'm sure that we have more than 42 different programming
languages in the archive, so obviously we don't need Java, right? You can
do all the same things in C++. Or hey, let's pick one of either Perl or
Python; they can both do the same things.

I can definitely come up with more than 42 different ways to write an
editor, all of which may appeal to different people, different tasks, or
different work styles. But hey, I like Emacs, which clearly does
everything that vi can do, so away with vim! And nvi just duplicates vim!

We probably don't need 42 different ways to find duplicate files on local
disk, since that's a relatively clear and well-defined task and there's
only so many ways to go about it (and each implementation could probably
gain the features of the others). But window managers are fundamental to
one's style of interaction with the computer, and there are *huge*
differences between them. A tiling window manager is not interchangeable
with a desktop environment, which in turn is not interchangeable with a
window manager designed to be operated without a mouse, or one that's
optimized for a particular class of accessibility issues. And that's not
even getting into the window managers that are used primarily because they
embed a particular scripting language that people want to use to automate
their windowing actions.

By all means, let's get rid of packages that really do only offer subsets
of functionality of other packages. But UI is part of functionality, and
a different UI *is* a different feature. By all means, let's get rid of
poorly-maintained packages. But if someone finds a package that does
something in a way that nothing else does and that fits them, and they're
able and willing to take care of it, having a place for those is one of
Debian's strengths. We should be improving our tools and management
techniques for handling large numbers of packages, including for retiring
them when they're not being maintained, not trying to reduce the variety
and depth of the distribution.

And as sympathetic as I am to the concern about RC bugs in packages that
are already in the archive, I suspect it's rather rare that fixing random
RC bugs in other people's packages is the compelling, fun thing that gets
someone involved in doing Debian development. I know it happens, but I
bet more people join the project the way that I did: there's some specific
piece of software that they want packaged for the distribution they
already use, so they package it, and from that learn how to package, and
from that branch out into helping with other parts of the distribution.

Getting one's own package into the distribution is a really awesome
feeling. I don't think it's good for the growth of the project, or for
attracting new contributors, to put too many roadblocks in the way of
someone feeling that.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87k3yvg...@windlord.stanford.edu

[Bart Martens]

On Sun, Jun 24, 2012 at 08:36:13PM +0100, Neil Williams wrote:
> On Sun, 24 Jun 2012 20:42:33 +0200
> Arno Töll <ar...@debian.org> wrote:
>
> > On 24.06.2012 19:51, Neil Williams wrote:
> > > Whatever happens, there is no place for yet another duplicate of
> > > packages which already have multiple duplicates in the archive.
> >
> > Letting alone the package in particular (I don't even know it, nor do I
> > care)
>
> (Neither do I, particularly - but Thomas' list made it just too
> obvious that there was no justification for the bug report at the time
> of filing.)
>
> >, I wonder where you'd draw that line. As you say yourself: There
> > are lots of alternative packages in the archive already. So, what makes
> > all the other alternatives acceptable but this one not?
> >
> > What makes 42 window manager acceptable but not 43?
>
> If it can be justified. That's what the objective comparison would need
> to demonstrate.

The rejection of #43 should be justified, for example with conclusions from
such comparison with the 42 other implementations.

> That's an established pattern in Debian -

Let's not call your personal view "an established pattern in Debian". Let's
debate this and find a consensus before documenting it and advertising it as
"an established pattern in Debian".

> if someone
> wants to add something which is the same as something else, there
> should be a good reason to introduce the new one in that it needs to be
> better than the existing ones in some way which isn't achievable just
> by patching one of the existing ones.

It is, in my opinion, OK that someone expresses an intent to package a 43th
implementation in public so that anyone can compare it with the 42 other
implementations and then argue why #43 would not be needed in Debian.

>
> Debian works on merit - packages and maintainers. Suggesting or
> packaging something which is without merit will usually result in
> complaints from your peers. Cope with it. Maintainers should not expect
> to be treated with kid gloves when what they are actually doing is
> wasting the free time of other volunteers.

You can prevent your free time from being wasted by ignoring this ITP. If you
actively want to keep the package of this ITP out of Debian, then you should
produce some reasonable arguments, maybe after comparing all 43
implementations. But then it's your choice for doing all that work. Please
don't blame the ITP submitter for wasting your time.

>
> We're used to 'Justification' as a concept for RC bugs, well an ITP is
> a bug in Debian and can also require justification. Some ITP bugs are
> simply invalid.

An ITP is an expression of an intent to package some software. It does by
itself not express "I have analysed every alternative in Debian and I think
this one is better". If you feel that this one is not better, then you should
justify the rejection of the ITP.

>
> Someone needs to make that call and as we're all part of the QA team,
> various people do it according to their own free time, work area,
> expertise and general levels of annoyance with daft ideas.

Yes, anyone can justify why an ITP should be rejected.

>
> Whether it's a joke package or a tiny package which needs to go into a
> collective package (goodies or devscripts or whatever), if maintainers
> (prospective or existing) can't do their own research ahead of filing a
> bug, it is up to the rest of us to point out the error.

Yes, you're right about this. That's what I understand in "peer review".

>
> > I'm not in favor to get yet another window manager in Debian. All I'm
> > saying is that filing a WNPP bug and wait whether a people complain loud
> > enough is not the way to learn that.

I think that it is OK that other people complain about an ITP. It is also OK
to be very clear about why an ITP in particular is not welcome. Of course,
politeness and friendliness are generally appreciated, and I think that this
aspect started the debate.

>
> So feel free to file a patch to the Developer Reference explaining that
> if maintainers of prospective packages don't check for existing packages
> which provide the same or very similar functionality, any request to
> package such a duplicate needs to be accompanied by a detailed
> reasoning of *why* the existing packages are sufficiently inadequate
> that a new package is warranted instead of patching what we have.

If you feel that Developer Reference can be improved, then feel free to do
suggestions. The above is not a suggestion I can support.

>
> To me, such an expectation is common sense and I'm quite happy to
> continue criticising ITP's on the basis of being an unjustifiable
> duplicate of existing packages.

It is good that you continue reviewing ITPs. But I would appreciate (and the
ITP submitter would probably also appreciate) that you justify rejecting ITPs
with good arguments and in a friendly way.

>
> > Especially since a WNPP bug
> > complaints are not worth that much. If you happen to find a DD to upload
> > your stuff or you are DD yourself, you can silently ignore any comments
> > if you like and upload nonetheless.
>
> At which point, the credibility of any such DD is diminished, as is
> the credibility of any DD who sponsors such packages despite
> complaints from his/her peers.

Yes, credibility and reputation are affected by uploads. Also by how one
rejects ITPs.

>
> > That's how we end up with 42 display manager. Complaining on the 43th is
> > not the way to go.
>
> The 43rd must be *justified* - there needs to be a reason why the lack
> of this package is a bug in Debian. Otherwise the request could just as
> well be reassigned as a wishlist bug against one of the alternatives.

Anyone is free to justify the rejection of #43 with good arguments.

>
> > Moreover, would you be a well respected Debian Developer today if your
> > replies to your first WNPP bug (if you filed any, I don't know) back
> > then told you to go away, nobody appreciates your work?
>
> As hinted in my previous post, I did my research before filing my first
> (and subsequent) ITP bugs. Nobody disagreed at the time and I have
> since removed the first package I introduced into Debian as it's time
> had passed. There were no duplicates but there was also no
> justification for it remaining in the archive for wheezy.

That sounds like you're doing good work on that.

>
> An ITP is meant to be a bug in Debian - that Debian is missing some
> functionality.

Or that the ITP submitter feels that the software is worth to be in Debian.

> It is perfectly acceptable to require that such
> functionality can be implemented in a different way by working with a
> package we already have.

Anyone can do the analysis of comparing alternatives already in Debian.

> Triaging bugs requires that the bugs are
> tested for validity before spending more time on the fix. No point
> putting the wrong fix into the archive.

True.

>
> However, I also had comments from other bugs once becoming a DD which
> showed where I'd gone wrong on those packages, but that just meant that
> I had to show I could accept criticism and just get on with fixing
> stuff. Those who did criticise me I now count as friends, so that is
> how I think Debian should work.

It is a good quality, in my opinion, to be able to accept criticism.

Regards,

Bart Martens

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120625070...@master.debian.org

[Serge]

2012/6/24 Thomas Koch wrote:

>> Package: wnpp
>> Severity: wishlist
>> Owner: "Mickaël Raybaud-Roig" <raybau...@gmail.com>
>>
>> * Package name : wmfs
>> Version : 2~beta201206
>> Upstream Author : Martin Duquesnoy <xor...@gmail.com>
>> * URL : http://wmfs.info
>> * License : BSD
>> Programming Lang: C
>> Description : Window Manager From Scratch
>>
>> « WMFS2 is a lightweight and highly configurable tiling window manager
>> for X written in C. wmfs2 is a free software distributed under the BSD
>> license. it can be drive from keyboard or mouse and it's configuration
>> stands in one text file easily understandable »

Users reading such description can be confused how is it different from
other existing WMs. So let's put some more details in this description:
> Its features include:
> * extendible application launcher with autocompletion (prompt).
> * built-in system tray.
> * Xinerama multi-head support.
> * extended window manager hints (EWMH) compliance.
> * editable rules for tags/clients.
> * complete mouse support.
> * on-the-fly configuration reloading.
> * dynamic tag creation/deletion.
> * statusbar with support for progressbar, color, images and status pipes.
> * manual layout: you can create/arrange layouts as you want/need.
> * tab, move and resize clients with direction.
> * themes support for statusbar and clients.
> * ”@include” support split configuration file.

At least that "statusbar" feature worth to be mentioned, since it makes
this WM unique. "EWMH", "themes" and "built-in system tray" looks also
important to me.

As a user I would also like to know:
* what's its focus model: focus-follows-mouse, click-to-focus, etc?
* does it have a GUI configuration?
* does it support workspaces?
* does it allow to move windows with mouse?
* does it support urgency hints (WM_HINTS, NET_WM_STATE_DEMANDS_ATTENTION)?
* is it just tiling? what about stacking mode or floating windows?
* is it utf8/unicode friendly? works for window titles in french or korean?
* is it translated to other languages?
* freetype/Xft or X core fonts?
* shape extension? round windows? (e.g. `xeyes`)
* how much RAM it takes?
* is it low-dependency (GTK/Qt/Tk/etc.)?

As a start point: what are its differences from i3-wm, awesome or wmii?

> I shortened the list to only include one line for each window manager
> already in Debian:

> [...]

Among those 41 WMs only 9 are tiling WMs. And just a few of those tiling
WMs are usable out-of-box without heavy configuring and long documentation
reading.

PS: IMHO, there's nothing bad in having several similar programs in
repository, as long as someone wants to maintain them. It gives additional
flexibility for users. I.e. if some of them die upstream or dropped by the
maintainer users would be able to use another one.

--
Just trying to help,
Serge

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAOVenEpv5ZH0w9kE67RDOsgw...@mail.gmail.com

[Mickaël Raybaud-Roig]

Hello,

First, thank to everyone for having responded.

I've read the list of window managers in Thomas Koch's email, and, as
said Serge, there are only a few tiling window managers in this list:


- Awesome requires programming skills
- Bluetile is for GNOME and there is no taskbar and no systray
- dwm hasno configuration file
- fvwm is very hard to setup
- herbstluftwm has no window decoration, no launcher, no taskbar and no systray
- i3-wm has a different behavior ("tree data structure")
- larswm seems very good, but there is no launcher, no widgets in the
taskbar and no window decoration
- matchbox seems to be for embedded systems
- ratpoison has no window decoration and no launcher
- xmonad has no window decoration and no launcher

I'm not saying that WMFS is better than those window manager or that
WMFS is perfect, but that WMFS offer another user experience than the
window managers already in the Debian archive.

As someone said in the thread, i forgotten to describe all the
caracteristics of WMFS.

So WMFS has the following features:

- it's lightwieght
- it's easily configurable
- it's not ugly
- there is are parametrable launcher (kind of prompts)
- there is a systray
- it supports Xinerama (for multiple displays)
- it's EWMH-compliant
- it supports rules
- you can use the mouse for almost everything
- you can reload the configuration on-the-fly
- it can dynamically create/delete tags
- you can add what you want in the taskbar/titlebars: progressbars,
graphs, buttons, colors, images ...
- the layout is manual
- you can tab several clients in one window
- it supports themes
- you can use includes to split the configuration
- you can control it remotely

Q: what's its focus model: focus-follows-mouse, click-to-focus, etc?
A: Both, you can select the one you want with the `focus` option in
the config file

Q: does it have a GUI configuration?
A: GVim ?

Q: does it support workspaces?
A: Yes, but that's called "tags"

Q: does it allow to move windows with mouse?
A: Yes, you can move, resize, tab, change tag and close with the mouse

Q: does it support urgency hints (WM_HINTS, NET_WM_STATE_DEMANDS_ATTENTION)?
A: Yes, it highlights the clients that demands attention with a color
of the theme

Q: is it just tiling? what about stacking mode or floating windows?
A: No, there is also a floating mode. Dialogs are in floating mode by default.

Q: is it utf8/unicode friendly? works for window titles in french or korean?
A: Good question, i will try that as soon as possible ...

Q: is it translated to other languages?
A: There is a French and a Spanish documentation on the wiki, but WMFS
just manage windows and draw titlebars/taskbars, so it doesn't speaks
english more than another language...

Q: freetype/Xft or X core fonts?
A: It supports freetype fonts

Q: shape extension? round windows? (e.g. `xeyes`)
A: I admit i haven't tryed...

Q: how much RAM it takes?
A: I haven't measured but its a lightweight program.

Q: is it low-dependency (GTK/Qt/Tk/etc.)?
A: It only depends of the Xlib, Xinerama and Imlib2

There is a wiki with more informations here:

https://github.com/xorg62/wmfs/wiki

The wiki also contains explainations about the configuration and
configuration examples:

https://github.com/xorg62/wmfs/wiki/Configuration-wmfsrc
https://github.com/xorg62/wmfs/wiki/Users-config
https://github.com/xorg62/wmfs/wiki/bonus

Have a nice day

--
Mickaël Raybaud-Roig <raybau...@gmail.com>

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CADx5VdoMuX1hFXLO+tJiH3D6...@mail.gmail.com

[Svante Signell]

On Mon, 2012-06-25 at 08:19 +0200, Antti-Juhani Kaijanaho wrote:
>
> Adam Borowski <kilo...@angband.pl> kirjoitti:
>
> >Sure, let's start removals with ones that hard-depend on things a
> >window
> >manager shouldn't touch, like network-manager.

Yes, why not!

> Which wm does that? I know it isn't gnome-shell at least, as I've been
> using it quite successfully without nm installed.

Have you tried to use evolution without NM?

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1340620722.5945.3.camel@x60

[Andrew Shadura]

Hello,

On Sun, 24 Jun 2012 20:36:13 +0100
Neil Williams <code...@debian.org> wrote:

> If it can be justified. That's what the objective comparison would
> need to demonstrate. That's an established pattern in Debian - if
> someone wants to add something which is the same as something else,
> there should be a good reason to introduce the new one in that it
> needs to be better than the existing ones in some way which isn't
> achievable just by patching one of the existing ones.

It is definitely not the same and not duplicate. Different window
managers look differently and feel a lot differently (I thought it
should be obvious enough, isn't it?).

More to say, I'd like to see this window manager in Debian, jugding
by its documentation it seems to be really great, flexible yet tiny and
easily configurable, so I support it's inclusion fully.

--
WBR, Andrew

[Tollef Fog Heen]

]] Neil Williams

> Popcon indicates almost nothing - least of all popularity. The
> weaknesses of popcon for archive-related questions is well documented.
> It might give a hint but it is *not* a reliable indicator.

While it's not perfect, I'm not aware of any better tool we have.
Relying on hearsay about what people install is worse.

> 99% of the Debian machines I install have no means of communicating via
> popcon - ever. What's installed on those is completely invisible.

It does not matter how many machines are installed without popcon as
long as it is installed on a representative sample. Whether that is the
case is open for debate, but unless and until somebody comes up with a
better tool and method than using popcon, that's what we have.

[...]

> Rubbish. Complete tosh.

You might want to reconsider your choice of words. You're coming across
as quite hostile in this thread.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87bok7z...@qurzaw.varnish-software.com

[Antti-Juhani Kaijanaho]

Svante Signell <svante....@telia.com> kirjoitti:

>On Mon, 2012-06-25 at 08:19 +0200, Antti-Juhani Kaijanaho wrote:
>> Which wm does that? I know it isn't gnome-shell at least, as I've
>been
>> using it quite successfully without nm installed.
>
>Have you tried to use evolution without NM?

Evolution is not, so far as I know, a window manager. And no,
I have never used it, with or without NM.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/8953d159-a56b-4756...@email.android.com

[Osamu Aoki]

Hi,

I am neutral about discussion on if one more WM should be uploaded or not.

I am concerned about this package description of ITP and I wish it is
improved if it is uploaded to Debian.

On Mon, Jun 25, 2012 at 11:38:52AM +0200, Mickaël Raybaud-Roig wrote:
...

>
> So WMFS has the following features:

...

> - it's not ugly

+ It is aesthetically pleasing.

> There is a wiki with more informations here:
>
> https://github.com/xorg62/wmfs/wiki
> The wiki also contains explainations about the configuration and
> configuration examples:

Emmm... Package description should capture essential part of these
features as much as possible in few paragraphs. Pointing to URL link
should not be the primary source of information.

Otherwise, how do we tell which package to install by reading its
description.

Osamu

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012062514...@goofy.localdomain

[Mickaël Raybaud-Roig]

2012/6/25 Osamu Aoki <os...@debian.org>:

> I am concerned about this package description of ITP and I wish it is
> improved if it is uploaded to Debian.

Hello,

In fact, i didn't realized that the ITP description will be the
description of the final package.

I will edit it as soon as possible (i am at work, and i don't have my
PGP key, so i dont know if i can, since i used PGP to send the ITP
...)

But how can-i edit the description ?
Shoud-i use this http://www.debian.org/Bugs/server-control.en.html#summary ?

Thank in advance

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CADx5VdpvV9DN0VG02KdcvD9j...@mail.gmail.com

[Neil Williams]

On Tue, 26 Jun 2012 09:57:52 +0200
Mickaël Raybaud-Roig <raybau...@gmail.com> wrote:

> 2012/6/25 Osamu Aoki <os...@debian.org>:
> > I am concerned about this package description of ITP and I wish it is
> > improved if it is uploaded to Debian.
>

> In fact, i didn't realized that the ITP description will be the
> description of the final package.
>
> I will edit it as soon as possible (i am at work, and i don't have my
> PGP key, so i dont know if i can, since i used PGP to send the ITP

Bug comments do not need PGP/GnuPG signatures - only uploads need those.

> But how can-i edit the description ?
> Shoud-i use this http://www.debian.org/Bugs/server-control.en.html#summary ?

Just add a comment that the final description will be ....

You can use summary with that, yes, but as long as it exists in the bug
log, people can look at the end of the log.

[Mickaël Raybaud-Roig]

2012/6/26 Neil Williams <code...@debian.org>:

Okay, thanks :-)

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CADx5Vdpz7kASuaYmR_GuQU4j...@mail.gmail.com

[Thomas Koch]

Hi Mickaël,

I'm sorry that I did not include a warm welcoming statement in my last
mail. I'm happy about everybody who is interested in Debian and even
considers doing packaging work. I've found a community of great
professionals, friendly people and extraordinary personalities among
Debian's contributors.

I'm looking forward to hear more of you or meet you at a free software
event, e.g. next year's debconf in Switzerland?

Thus having said, I believe that the world (and Debians archive) does
have all the window managers it needs. :-)

Regards, Thomas Koch

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87bok5b...@koch.ro

[Philipp Kern]

On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote:
> > Which wm does that? I know it isn't gnome-shell at least, as I've been
> > using it quite successfully without nm installed.
> Have you tried to use evolution without NM?

I didn't try but it only suggests network-manager. However some applications do
behave weird if you just deinstalled n-m (pidgin for instance), because they
assume that you're not connected. After a reboot (maybe dbus restart is enough)
they certainly connect again, though.

Kind regards
Philipp Kern

[Mickaël Raybaud-Roig]

2012/6/27 Thomas Koch <thk...@koch.ro>:
> Hi Mickaël,
Hi,

> I'm sorry that I did not include a warm welcoming statement in my last
> mail. I'm happy about everybody who is interested in Debian and even
> considers doing packaging work. I've found a community of great
> professionals, friendly people and extraordinary personalities among
> Debian's contributors.

No problem :-)

> I'm looking forward to hear more of you or meet you at a free software
> event, e.g. next year's debconf in Switzerland?

I don't think: it's a bit far, and anyway, i dont speak english well
enough to go to conferences in english :-p


Regards, Mickaël Raybaud-Roig

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CADx5VdpvE3Mt9hAYC_rkhPN...@mail.gmail.com

[Holger Levsen]

On Mittwoch, 27. Juni 2012, Thomas Koch wrote:
> Thus having said, I believe that the world (and Debians archive) does
> have all the window managers it needs. :-)

I beg to differ. To say it mildy :)

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/201206280058...@layer-acht.org

[Bruce Sass]

On June 28, 2012 12:58:09 AM Holger Levsen wrote:
> On Mittwoch, 27. Juni 2012, Thomas Koch wrote:
> > Thus having said, I believe that the world (and Debians archive) does
> > have all the window managers it needs. :-)
>
> I beg to differ. To say it mildy :)

+1 (says the guy building UDE from source)

As someone pointed out earlier, there are lots of different tastes when it
comes to window manager-like software... I expect there are more tastes than
available WMs--so, the more the merrier as long as its maintained.

- Bruce

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/201206280754...@shaw.ca

[Mickaël Raybaud-Roig]

Hi,

I've re-uploaded the package:

http://mentors.debian.net/debian/pool/main/w/wmfs/wmfs_2~beta201206-3.dsc

Now it should works.


Regards, Mickaël Raybaud-Roig

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CADx5Vdrc4bdMa2xLhZzdCLy6...@mail.gmail.com

[Adam Borowski]

On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote:
> On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote:
> > > Which wm does that? I know it isn't gnome-shell at least, as I've been
> > > using it quite successfully without nm installed.
> > Have you tried to use evolution without NM?

Evolution seems to work just fine.

> I didn't try but it only suggests network-manager. However some applications do
> behave weird if you just deinstalled n-m (pidgin for instance), because they
> assume that you're not connected. After a reboot (maybe dbus restart is enough)
> they certainly connect again, though.

I tested a good part of Gnome today without n-m and it appears there are no
regressions at all. The only differences are:

* it gets rid of n-m icon in the systray (duh)

The dependency comes via gnome-core depending on network-manager-gnome.

>
> Kind regards
> Philipp Kern

--
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120708144...@angband.pl

[Adam Borowski]

WHOOPS, SORRY. Meant to delete this old draft, not send it.
The issue is valid, but sorry for incomplete mail.

On Sun, Jul 08, 2012 at 04:48:01PM +0200, Adam Borowski wrote:
> On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote:
> > On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote:
> > > > Which wm does that? I know it isn't gnome-shell at least, as I've been
> > > > using it quite successfully without nm installed.
> > > Have you tried to use evolution without NM?
>
> Evolution seems to work just fine.
>
> > I didn't try but it only suggests network-manager. However some applications do
> > behave weird if you just deinstalled n-m (pidgin for instance), because they
> > assume that you're not connected. After a reboot (maybe dbus restart is enough)
> > they certainly connect again, though.
>
> I tested a good part of Gnome today without n-m and it appears there are no
> regressions at all. The only differences are:
>
> * it gets rid of n-m icon in the systray (duh)

[was incomplete]
* "network settings" deep in the control panel will say the networking on
this system is not compatible


Since n-m breaks actually working software (udev, ifupdown) for non-obscure
uses (connecting a phone via USB, bridged setups, non-basic VPNs, etc), a
desktop environment hard-depending on it is bad, and this really needs to be
a Recommends: relationship instead.

N-M compared to ifupdown:
* makes things easier for new users (good! especially in a default install)
* is said to make wifi easier (when it works...)
And downsides:
* breaks usb0 completely (keeps raising and lowering the interface in a
loop, no apparent way to tell it to keep its grubby hands away)
* breaks a load of complex setups

"Breaks unrelated software" on the system is a RC severity, and there's no
way one can say a windowing environment is related to core networking.
Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to
Recommends: is a non-intrusive fix. It will cause n-m to be installed
unless explicitely refused, just like you want it to be.

On the other hand, breaking such setups is not a RC bug in n-m. Like any
non-core package, there is no requirement for it to be universal:
* not working with complex setups is at most wishlist
* breaking USB networking by flipping the interface is normal
It's just gnome-meta hard-depending on it what's wrong.

[Noel David Torres Taño]

First of all I'm not a DD but just a Maintainer of 2 packages and a long time user.

 

Since I fled away from KDE and felt into Gnome in Debian, I'm using it without N-M installed. It is only a matter of dpkg -force-depends -P two packages every time aptitude "corrects" my system when I install something, and I must say I'm more than happy by not having N-M: nothing messes with my network configuration (which is non-standard) and also users (my wife, or even myself using my normal account) can not disable networking nor break it.

 

I have not tried Evolution (I use kmail even in Gnome and my wife uses Icedove) but I can say that Pidgin works better without N-M than with it.

 

Regards (and thanks for all the time you spend that makes Debian my distro of choice)

[Ian Jackson]

Adam Borowski writes ("Re: duplicates in the archive"):

> "Breaks unrelated software" on the system is a RC severity, and there's no
> way one can say a windowing environment is related to core networking.
> Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to
> Recommends: is a non-intrusive fix. It will cause n-m to be installed
> unless explicitely refused, just like you want it to be.

I definitely think this should be fixed for wheezy.

Adam earlier wrote on -devel:

I tested a good part of Gnome today without n-m and it appears there
are no regressions at all. The only differences are:

* it gets rid of n-m icon in the systray (duh)

The dependency comes via gnome-core depending on
network-manager-gnome.

To the Gnome maintainers: given that Adam has done this test, to check
that things are OK without n-m, would you be willing to make this
change to the gnome-core metapackage ?

Thanks,
Ian.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20475.10012....@chiark.greenend.org.uk

[Adam Borowski]

On Mon, Jul 09, 2012 at 07:46:52PM +0100, Ian Jackson wrote:
> Adam Borowski writes ("Re: duplicates in the archive"):
> > "Breaks unrelated software" on the system is a RC severity, and there's no
> > way one can say a windowing environment is related to core networking.
> > Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to
> > Recommends: is a non-intrusive fix. It will cause n-m to be installed
> > unless explicitely refused, just like you want it to be.
>

> I tested a good part of Gnome today without n-m and it appears there
> are no regressions at all. The only differences are:
>
> * it gets rid of n-m icon in the systray (duh)

Actually, the very mail you reference, contains an continuation (with
apologies for accidentally pressing 'y' instead of 'q'):

} [was incomplete]
} * "network settings" deep in the control panel will say the networking on
} this system is not compatible

and also, as Philipp Kern noticed before, things that use N-M to distinguish
between online and offline modes will think they're offline after
uninstalling N-M until they are restarted.

Of course, none of the three are a big deal, at least comparing to not being
able to connect a phone or use complex networking.

--
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition. For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623

[Félix Arreola Rodríguez]

El lun, 09-07-2012 a las 19:46 +0100, Ian Jackson escribió:
> Adam Borowski writes ("Re: duplicates in the archive"):
> > "Breaks unrelated software" on the system is a RC severity, and there's no
> > way one can say a windowing environment is related to core networking.
> > Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to
> > Recommends: is a non-intrusive fix. It will cause n-m to be installed
> > unless explicitely refused, just like you want it to be.
>
> I definitely think this should be fixed for wheezy.
>
> Adam earlier wrote on -devel:
>
> I tested a good part of Gnome today without n-m and it appears there
> are no regressions at all. The only differences are:
>
> * it gets rid of n-m icon in the systray (duh)
>
> The dependency comes via gnome-core depending on
> network-manager-gnome.
>
> To the Gnome maintainers: given that Adam has done this test, to check
> that things are OK without n-m, would you be willing to make this
> change to the gnome-core metapackage ?
>
> Thanks,
> Ian.
>
>

A system without network-manager is still usable even for desktop users.

I mean, for example, when Pidgin opens, and n-m is not available, it
just tries to connect directly to internet. When pidgin opens, and n-m
is active pidgin waits to connect until n-m gets connected. Sometimes is
annoying because other network interfaces may be active with full
internet and pidgin waits until n-m reports ready.

A similiar experience happens with Evolution.

But, ignoring the "a desktop works fine without n-m" thing, n-m makes
more, much more easy connecting to wifi networks, espeacially for
laptops. I suggest make Laptop task depend on n-m, in this way, n-m
don't get installed on desktop systems, just on laptop systems.

--
Atte. Félix Arreola Rodríguez,
Firmado con GPG, llave 1E249EE4

[Miles Bader]

Félix Arreola Rodríguez <fgatu...@gmail.com> writes:
> But, ignoring the "a desktop works fine without n-m" thing, n-m makes
> more, much more easy connecting to wifi networks, espeacially for
> laptops. I suggest make Laptop task depend on n-m, in this way, n-m
> don't get installed on desktop systems, just on laptop systems.

What's wrong with Recommends: in that case? It seems to perfectly
match the "makes life easier for <common but not universal use-case
XXX>" scenario you describe.

A hard package-dependency in a case like this, when there isn't
actually any hard functional dependency, and there are issues with the
depended-upon package, are decidedly user-unfriendly.

[Yeah, the various desktops tend to abuse hard-dependencies in a lot
of other ways, but ... in most cases this just results in bloat. NM
is a bit worse than that.]

-Miles

--
Brain, n. An apparatus with which we think we think.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/878vest...@catnip.gol.com

[Jon Dowland]

On Mon, Jul 09, 2012 at 11:13:16PM +0200, Adam Borowski wrote:
> and also, as Philipp Kern noticed before, things that use N-M to
> distinguish between online and offline modes will think they're offline
> after uninstalling N-M until they are restarted.

You get this even with n-m installed, if n-m isn't managing your connection.
So for example I have n-m configured for wifi and 3g connections, but
ignoring my ethernet connection, so I can use a bridged setup. Various
desktop apps misbehave in minor ways: pidgin as already mentioned; chrome
reports "unable to connect to Internet" instead of more nuanced failures such
as "no such site", etc.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120710084754.GB24054@debian

[Josselin Mouette]

Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
> What's wrong with Recommends: in that case? It seems to perfectly
> match the "makes life easier for <common but not universal use-case
> XXX>" scenario you describe.

Recommends is wrong for metapackages because it gets upgrades very
wrong. This is why it is used very marginally.

> A hard package-dependency in a case like this, when there isn't
> actually any hard functional dependency, and there are issues with the
> depended-upon package, are decidedly user-unfriendly.

It is unfriendly to the extreme minority of users who want a specific
selection of packages rather than the default metapackages.

Accidentally these are the users who also have the ability to make their
own package selection.

--
.''`. Josselin Mouette
: :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1341927163.10559.1.camel@pi0307572

[Eugene V. Lyubimkin]

[ dropping 542095@ ]

Hi,

On 2012-07-10 15:32, Josselin Mouette wrote:
> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
> > What's wrong with Recommends: in that case? It seems to perfectly
> > match the "makes life easier for <common but not universal use-case
> > XXX>" scenario you describe.
>
> Recommends is wrong for metapackages because it gets upgrades very
> wrong. This is why it is used very marginally.

Standards should not depend on implementation details. I see zero
reasons why metapackages are (or should be) specific here. Whatever $it
that gets upgrades wrong should be fixed instead.

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

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120710135212.GA5107@r500-debian

[Gergely Nagy]

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

> On 2012-07-10 15:32, Josselin Mouette wrote:
>> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
>> > What's wrong with Recommends: in that case? It seems to perfectly
>> > match the "makes life easier for <common but not universal use-case
>> > XXX>" scenario you describe.
>>
>> Recommends is wrong for metapackages because it gets upgrades very
>> wrong. This is why it is used very marginally.
>
> Standards should not depend on implementation details. I see zero
> reasons why metapackages are (or should be) specific here. Whatever $it
> that gets upgrades wrong should be fixed instead.

But the purpose of the meta-package is to pull stuff in. Depends does
that, Recommends does not, therefore Recommends is not appropriate for
the task.

For the cases where one wants to have most of the stuff installed that
the meta-package would pull in, but not all, solutions already
exist. And like Josselin said in the same mail, there is a large overlap
between those who want to push some of the stuff in Depends to
Recommends, and those who can just make their own local meta-package
within 5 minutes and be done with it.

--
|8]

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87obnnz...@algernon.balabit

[Eugene V. Lyubimkin]

On 2012-07-10 16:18, Gergely Nagy wrote:
> But the purpose of the meta-package is to pull stuff in. Depends does
> that, Recommends does not, therefore Recommends is not appropriate for
> the task.

Surely Recommends does pull stuff in. It's clearly reflected in Debian
policy and supported by most if not all high-level packages managers in
Debian. Therefore it's totally appropriate for the task.

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

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120710151412.GB5107@r500-debian

[Abou Al Montacir]

On Tue, 2012-07-10 at 09:47 +0100, Jon Dowland wrote:

On Mon, Jul 09, 2012 at 11:13:16PM +0200, Adam Borowski wrote:
> and also, as Philipp Kern noticed before, things that use N-M to
> distinguish between online and offline modes will think they're offline
> after uninstalling N-M until they are restarted.

You get this even with n-m installed, if n-m isn't managing your connection.
So for example I have n-m configured for wifi and 3g connections, but
ignoring my ethernet connection, so I can use a bridged setup.  Various
desktop apps misbehave in minor ways: pidgin as already mentioned; chrome
reports "unable to connect to Internet" instead of more nuanced failures such
as "no such site", etc.

I was using gnome with n-m installed but deactivated (just remove /etc/rc*/netwrok-manager) without any issue. The reason for removing the rc*/n-m is that when starting n-m, evolution will refuse to connect to the "unmanaged" eth0 (static iface managed with ifup/ifdown). When n-m is stopped, evolution just will detect this and fallback to classical interface.

I did not notice any other gnome application that depends on n-m on its apparent behavior. So I can certify this Depends is not required.

Cheers,

[Jonas Smedegaard]

On 12-07-10 at 06:14pm, Eugene V. Lyubimkin wrote:
> On 2012-07-10 16:18, Gergely Nagy wrote:
> > But the purpose of the meta-package is to pull stuff in. Depends
> > does that, Recommends does not, therefore Recommends is not
> > appropriate for the task.
>
> Surely Recommends does pull stuff in. It's clearly reflected in Debian
> policy and supported by most if not all high-level packages managers
> in Debian. Therefore it's totally appropriate for the task.

Recommends does not _ensure_ that all is pulled in.

The very purpose of a meta-package is to _ensure_ that a certain set of
packages is installed, not just recommend them: All (not only most)
users of that package need all its dependencies satisfied - those that
don't should simply uninstall the meta-package.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

[Abou Al Montacir]

On Tue, 2012-07-10 at 18:10 +0200, Jonas Smedegaard wrote:

On 12-07-10 at 06:14pm, Eugene V. Lyubimkin wrote:
> On 2012-07-10 16:18, Gergely Nagy wrote:
> > But the purpose of the meta-package is to pull stuff in. Depends 
> > does that, Recommends does not, therefore Recommends is not 
> > appropriate for the task.
> 
> Surely Recommends does pull stuff in. It's clearly reflected in Debian 
> policy and supported by most if not all high-level packages managers 
> in Debian.  Therefore it's totally appropriate for the task.

Recommends does not _ensure_ that all is pulled in.

The very purpose of a meta-package is to _ensure_ that a certain set of 
packages is installed, not just recommend them: All (not only most) 
users of that package need all its dependencies satisfied - those that 
don't should simply uninstall the meta-package.

Exactly! And as confirmation see below you will see gnome recommending and even suggesting, which is probably fine:

aptitude show gnome
Package: gnome                          
State: installed
Automatically installed: yes
Version: 1:3.0+9
Priority: optional
Section: gnome
Maintainer: Debian GNOME Maintainers <pkg-gnome-...@lists.alioth.debian.org>
Architecture: i386
Uncompressed Size: 52.2 k
Depends: gnome-core (= 1:3.0+9), desktop-base, alacarte (>= 0.13.2), cheese (>= 3.0), ekiga (>= 3.2), evolution (>= 3.0), evolution-plugins (>= 3.0),
         file-roller (>= 3.0), gedit (>= 3.0), gnome-documents, gnome-games (>= 1:3.0), gnome-orca (>= 3.2), gnome-nettool (>= 3.0), hamster-applet (>=
         2.91.2), seahorse (>= 3.0), tomboy (>= 1.6) | gnote, vinagre (>= 3.0), abiword (>= 2.8) | libreoffice-gnome, avahi-daemon, gimp (>= 2.6),
         gnome-media (>= 2.91), gnumeric (>= 1.10) | libreoffice-gnome, inkscape (>= 0.48), rhythmbox (>= 2.90), shotwell, simple-scan, sound-juicer (>=
         2.32.1+20110330), transmission-gtk, xdg-user-dirs-gtk, libatk-adaptor, cups-pk-helper (>= 0.1.2), epiphany-extensions (>= 3.0), gedit-plugins (>=
         3.0), gnome-applets (>= 2.91), gstreamer0.10-ffmpeg (>= 0.10.12), gstreamer0.10-plugins-ugly (>= 0.10.18), gvfs-bin, nautilus-sendto (>= 3.0),
         rhythmbox-plugins, rhythmbox-plugin-cdrecorder, telepathy-gabble, telepathy-salut, totem-plugins, libgtk2-perl (>= 1:1.130)
Recommends: browser-plugin-gnash, gdebi, gnome-games-extra-data (>= 3.0), liferea | evolution-rss | blam, menu-xdg, nautilus-sendto-empathy, telepathy-idle
Suggests: dia-gnome, gnucash, libreoffice-gnome, libreoffice-evolution, planner, gnome-tweak-tool

saida:~# aptitude show gnome-core
Package: gnome-core                     
State: installed
Automatically installed: yes
Version: 1:3.0+9
Priority: optional
Section: gnome
Maintainer: Debian GNOME Maintainers <pkg-gnome-...@lists.alioth.debian.org>
Architecture: i386
Uncompressed Size: 52.2 k
Depends: brasero (>= 3.0), dconf-gsettings-backend (>= 0.7.5), dconf-tools (>= 0.7.5), empathy (>= 3.0), eog (>= 3.0), epiphany-browser (>= 3.0), evince (>=
         3.0), evolution-data-server (>= 3.0), fonts-cantarell, sound-theme-freedesktop, gcalctool (>= 6.0), gconf2 (>= 2.32), gdm3 (>= 3.0), glib-networking
         (>= 2.28.7), gnome-backgrounds (>= 3.0), gnome-bluetooth (>= 3.0), gnome-contacts, gnome-control-center (>= 1:3.0), gnome-disk-utility (>= 3.0),
         gnome-icon-theme (>= 3.0), gnome-icon-theme-extras (>= 3.0), gnome-icon-theme-symbolic (>= 3.0), gnome-keyring (>= 3.0), libpam-gnome-keyring (>=
         3.0), gnome-menus (>= 3.0), gnome-packagekit (>= 3.0), gnome-panel (>= 3.0), gnome-power-manager (>= 3.0), gnome-screensaver (>= 3.0), gnome-session
         (>= 3.0), gnome-session-fallback (>= 3.0), gnome-settings-daemon (>= 3.0), gnome-shell (>= 3.0), gnome-system-monitor (>= 3.0), gnome-terminal (>=
         3.0), gnome-themes-standard (>= 3.0), gnome-user-guide (>= 3.0), gnome-user-share (>= 3.0), baobab (>= 3.0), gnome-dictionary (>= 3.0),
         gnome-screenshot (>= 3.0), gnome-search-tool | tracker-gui, gnome-system-log (>= 3.0), gnome-font-viewer (>= 3.0), gsettings-desktop-schemas (>=
         3.0), gstreamer0.10-plugins-base (>= 0.10.34), gstreamer0.10-plugins-good (>= 0.10.29), gstreamer0.10-pulseaudio (>= 0.10.29), libgail-3-common (>=
         3.0) | libgtk-3-common (>= 3.2), gucharmap (>= 1:3.0), gvfs-backends (>= 1.8), libcanberra-pulse, metacity (>= 1:2.34), nautilus (>= 3.0),
         network-manager-gnome (>= 0.9), notification-daemon (>= 0.7), policykit-1-gnome, pulseaudio, totem (>= 3.0), vino (>= 3.0), yelp (>= 3.0), zenity
         (>= 3.0)
Suggests: gnome
Description: The GNOME Desktop Environment -- essential components


The most logical is that gnome-core does not depend on network-manager-gnome but the gnome package do. Indeed, experienced users will install gnome-core and select the rest manually.

[Eugene V. Lyubimkin]

On 2012-07-10 18:10, Jonas Smedegaard wrote:
> The very purpose of a meta-package is to _ensure_ that a certain set of
> packages is installed, not just recommend them: All (not only most)
> users of that package need all its dependencies satisfied

My definition of meta-package is less strict than yours. I as user
sometimes want '[meta]package X, but without packages Y and Z', and your
definition absolutely rules that out.

I saw many questions on forums like

"I did '$packagemanager install $metapackage' and then after
'$packagemanager remove $singlepackage', why $packagemanager now wants
to remove all $metapackage?"

, so I know I'm not alone. Using Recommends for non-core parts of
metapackages' dependencies would nicely solve that.

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


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120710163528.GC5107@r500-debian

[Gergely Nagy]

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

> On 2012-07-10 16:18, Gergely Nagy wrote:
>> But the purpose of the meta-package is to pull stuff in. Depends does
>> that, Recommends does not, therefore Recommends is not appropriate for
>> the task.
>
> Surely Recommends does pull stuff in.

No. Only if installing recommends is turned on, which cannot be
guaranteed.

> It's clearly reflected in Debian policy

No, it is not.

"Recommends

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found together
with this one in all but unusual installations."

Nowhere does that say that whatever is in recommends, will be
installed. Therefore, tools will *not* pull those in, unless they are
asked to.

> and supported by most if not all high-level packages managers in
> Debian.

Yes, apt and aptitude supports Apt::Install-Recommends, and it is
enabled by default. But it can - and often is - turned off.

> Therefore it's totally appropriate for the task.

It is not, because the purpose of the meta package is to get things
installed *always*. If it would be an optional collection of stuff, it
wouldn't be a meta package.

But, to cut the story short, attached to this mail is a script you can
use to take any metapackage, and remove (or demote) any of its
dependencies. It echoes a control-file thingy, combining it with equivs
is left as an excercise to the reader.

Usage:

$ ./meta-gen.sh gnome-core network-manager-gnome

Build a local package out of that, use happily ever after. Our
meta-packages can continue depending on what upstream considers part of
a package suite, and those of you who want to have most, but not all of
it, can use the script to create a local meta package. Since it's
scripted, you can even keep the local thing reasonably up to date.

It took about ~5 minutes to write that script, would take another 10 or
so to make it build a local package too. I'm fairly sure this could be
hooked into apt via a Apt::Update::Post-Invoke: once apt-get update ran,
update the local meta packages, push it to a local repo, touch a stamp
file, and update again. But perhaps there's even a way to make this play
nicer, I didn't care that much.

Crude, but should work, with about ~20 minutes of total time spent on
it. Much less than pointless arguing on a list about something that's so
very easy to solve in a way that everyone wins.

--
|8]

[Sune Vuorela]

On 2012-07-10, Gergely Nagy <alge...@balabit.hu> wrote:
> No. Only if installing recommends is turned on, which cannot be
> guaranteed.

There is many ways to break your system. turning off installation of
recommends is one of them.


That said, recommends is not to be used for metapackages. with
metapackages you want to ensure *what* the user has installed.

/Sune

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/slrnjvomlf...@sshway.ssh.pusling.com

[Charles Plessy]

Hello everybody,

perhaps people interested in discussing metapackages and Recommends can have a
look to the rejected DEP 6 and the associated thread.

http://dep.debian.net/deps/dep6/

http://lists.debian.org/debian-devel/2009/12/msg00550.html

Have a nice day,

--
Charles Plessy
Illkirch-Graffenstaden, France

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012071016...@falafel.plessy.net

[Gergely Nagy]

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

> On 2012-07-10 18:10, Jonas Smedegaard wrote:
>> The very purpose of a meta-package is to _ensure_ that a certain set of
>> packages is installed, not just recommend them: All (not only most)
>> users of that package need all its dependencies satisfied
>
> My definition of meta-package is less strict than yours. I as user
> sometimes want '[meta]package X, but without packages Y and Z', and your
> definition absolutely rules that out.

That's not a meta package then. That's a collection of loosely coupled
stuff, and by that definition, a meta package should not use depends at
all, but always recommends, because someone may want to use metapackage
X, but without A, B and C. Might aswell get rid of them then.

> I saw many questions on forums like
>
> "I did '$packagemanager install $metapackage' and then after
> '$packagemanager remove $singlepackage', why $packagemanager now wants
> to remove all $metapackage?"
>
> , so I know I'm not alone. Using Recommends for non-core parts of
> metapackages' dependencies would nicely solve that.

Well, in case of GNOME, upstream considers n-m to be part of the core
system, to the best of my knowledge. If upstream does so, so should we.

Besides, the solution is very easy: don't want all the deps of the meta?
Don't install it. If you still want to pull most in, but exclude some,
see the script I posted earlier. It can easily be changed to echo an
apt-get line instead of a modified control file, if that's more
suitable.

--
|8]

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/874npfz...@algernon.balabit

[Ben Hutchings]

On Tue, Jul 10, 2012 at 04:39:10PM +0000, Sune Vuorela wrote:
> On 2012-07-10, Gergely Nagy <alge...@balabit.hu> wrote:
> > No. Only if installing recommends is turned on, which cannot be
> > guaranteed.
>
> There is many ways to break your system. turning off installation of
> recommends is one of them.

Quite.

> That said, recommends is not to be used for metapackages. with
> metapackages you want to ensure *what* the user has installed.

I don't see that at all. Metapackages are a convenience for
administrators and installer developers, not a shortcut for package
developers to determine what the user has installed (e.g. they don't
usually specify versionded depedencies). As already pointed out,
'gnome' does recommend and suggest some packages that are not strictly
required.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012071016...@decadent.org.uk

[Gergely Nagy]

Sune Vuorela <nos...@vuorela.dk> writes:

> On 2012-07-10, Gergely Nagy <alge...@balabit.hu> wrote:
>> No. Only if installing recommends is turned on, which cannot be
>> guaranteed.
>
> There is many ways to break your system. turning off installation of
> recommends is one of them.

During the past ~14 years I've been using Debian with that setting
turned off, nothing ever broke on my systems because of this setting. If
it does, then I'll consider that a bug and report it appropriately.

--
|8]

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87wr2by...@algernon.balabit

[Adam Borowski]

On Tue, Jul 10, 2012 at 03:32:43PM +0200, Josselin Mouette wrote:
> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
> > What's wrong with Recommends: in that case? It seems to perfectly
> > match the "makes life easier for <common but not universal use-case
> > XXX>" scenario you describe.
>
> Recommends is wrong for metapackages because it gets upgrades very
> wrong. This is why it is used very marginally.

In the general case, yes. This needs to be fixed. But it's not relevant
here because squeeze had network-manager-gnome already. So we have three
scenarios:

* a new install. Recommends will pull in n-m unless explicitely rejected.

* upgrade from squeeze (or earlier sid). Network-manager-gnome will be
upgraded if present, and if it has been removed, that was not without a
cause.

* debfoster/aptitude/"apt-get autoremove". Recommends will keep n-m-g safe
from autoremoval.

The problem with recommends is that they fail to pull in *new* relationships
of an existing package, this is not what's the case here.

> > A hard package-dependency in a case like this, when there isn't
> > actually any hard functional dependency, and there are issues with the
> > depended-upon package, are decidedly user-unfriendly.
>
> It is unfriendly to the extreme minority of users who want a specific
> selection of packages rather than the default metapackages.

So you call people who want to connect a smartphone an "extreme minority"?
The last time I checked, it's hard to find a person without one. USB
cables seem to be more popular than wall chargers, and a good part of phones
can transfer data over them. It also gets you an order of magnitude better
transfer speed than wifi, and you don't have wifi everywhere.

Folks who want to connect more than one machine via a VPN are also not that
rare among Debian users. Or ones with a bridged setup. Those are more
technical, yeah, but:

> Accidentally these are the users who also have the ability to make their
> own package selection.

except that unless you sit deeply in Gnome development, you don't know which
exactly components you need. This is precisely what a metapackage is for.
Am I supposed to know by heart whether the file manager is called "nautilus"
or "caja" this week? Or what do I need to install to have clicking an image
show me its contents?

[Nikolaus Rath]

Gergely Nagy <alge...@balabit.hu> writes:
> But, to cut the story short, attached to this mail is a script you can
> use to take any metapackage, and remove (or demote) any of its
> dependencies. It echoes a control-file thingy, combining it with equivs
> is left as an excercise to the reader.

If I'm not mistaken, that means that the demoted dependency will get
pulled in again on the next upgrade of the metapackage, or that I have
to put the metapackage on hold and will loose any demotions and
promotions of other packages in future metapackage versions.


Best,

-Nikolaus

--
»Time flies like an arrow, fruit flies like a Banana.«

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87mx37t...@inspiron.ap.columbia.edu

[Jonas Smedegaard]

On 12-07-10 at 06:34pm, Abou Al Montacir wrote:
> On Tue, 2012-07-10 at 18:10 +0200, Jonas Smedegaard wrote:
> > The very purpose of a meta-package is to _ensure_ that a certain set
> > of packages is installed, not just recommend them: All (not only
> > most) users of that package need all its dependencies satisfied -
> > those that don't should simply uninstall the meta-package.
>
> Exactly! And as confirmation see below you will see gnome recommending
> and even suggesting, which is probably fine:

[lots of more or less unrelated package dependencies snipped]

> The most logical is that gnome-core does not depend on
> network-manager-gnome but the gnome package do. Indeed, experienced
> users will install gnome-core and select the rest manually.

I disagree: Looking at the many other dependencies of gnome-core, it
clearly isn't meant as "smallest possible GNOME setup" but more
"essential parts of what the upstream GNOME project has to offer" - as
its package description also clearly reflects.

When I want "smallest possible GNOME setup" i install gnome-session.

[Nikolaus Rath]

Gergely Nagy <alge...@balabit.hu> writes:
> For the cases where one wants to have most of the stuff installed that
> the meta-package would pull in, but not all, solutions already exist.

What solutions do you mean?

Best,

-Nikolaus

--
»Time flies like an arrow, fruit flies like a Banana.«

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87pq83t...@inspiron.ap.columbia.edu

[Jonas Smedegaard]

On 12-07-10 at 07:35pm, Eugene V. Lyubimkin wrote:
> On 2012-07-10 18:10, Jonas Smedegaard wrote:
> > The very purpose of a meta-package is to _ensure_ that a certain set
> > of packages is installed, not just recommend them: All (not only
> > most) users of that package need all its dependencies satisfied
>
> My definition of meta-package is less strict than yours. I as user
> sometimes want '[meta]package X, but without packages Y and Z', and
> your definition absolutely rules that out.
>
> I saw many questions on forums like
>
> "I did '$packagemanager install $metapackage' and then after
> '$packagemanager remove $singlepackage', why $packagemanager now wants
> to remove all $metapackage?"
>
> , so I know I'm not alone.

As users we play around with the possibilities of the Debian system, and
not always get it right. Sometimes we misunderstand parts of the system
design wrongly and do not enjoy the full potential of Debian for ages,
until learning more - and often parallel to that Debian improving to be
more clear in its intended use.

You being alone does not make you right.

A package manager wanting to remove all dependencies of a meta-package
is quite sensible - when you understand the sense of it. Until then it
is utterly confusing.

> Using Recommends for non-core parts of
> metapackages' dependencies would nicely solve that.

...but I disagree that making meta-packages more elastic is a "nice"
solution: is a hack covering over misguided users. Possible solutions
could be improved documentation and improved design of package managers.

[Andrei POPESCU]

On Ma, 10 iul 12, 18:43:03, Gergely Nagy wrote:
>
> During the past ~14 years I've been using Debian with that setting
> turned off, nothing ever broke on my systems because of this setting. If
> it does, then I'll consider that a bug and report it appropriately.

Depending on how you do the package selection on your next installation
you might end up with rsyslog, but without logrotate[1].

This is just one example of ways to break your system by not installing
recommends.

[1] which makes sense, given that the admin may want to use rsyslog with
remote logging.

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

[Eugene V. Lyubimkin]

On 2012-07-10 20:15, Jonas Smedegaard wrote:
> On 12-07-10 at 07:35pm, Eugene V. Lyubimkin wrote:
> > On 2012-07-10 18:10, Jonas Smedegaard wrote:
> > > The very purpose of a meta-package is to _ensure_ that a certain set
> > > of packages is installed, not just recommend them: All (not only
> > > most) users of that package need all its dependencies satisfied
> >
> > My definition of meta-package is less strict than yours. I as user
> > sometimes want '[meta]package X, but without packages Y and Z', and
> > your definition absolutely rules that out.
> >
> > I saw many questions on forums like
> >
> > "I did '$packagemanager install $metapackage' and then after
> > '$packagemanager remove $singlepackage', why $packagemanager now wants
> > to remove all $metapackage?"
> >
> > , so I know I'm not alone.
>

> [...]

> You being alone does not make you right.
>
> A package manager wanting to remove all dependencies of a meta-package
> is quite sensible - when you understand the sense of it. Until then it
> is utterly confusing.

As someone who developed a high-level package manager for Debian from
scratch (including the autoremoval functionality) I'm pretty sure I
understand the sense of it. My message was: users who don't (yet)
understand the full picture, find that behavior confusing, and it takes
time to explain. Moreover, despite me understanding the picture, I still
has no clean, safe and documented way to do what I'd want in case the
package maintainer chosed Depends.

Next, I don't pretend I'm "right", I do pretend there are >= 1 person
who don't need all dependencies of the metapackage installed, and hence
your 'All [...] users of that package need all its dependencies
satisfied' clause is wrong. You can argue that it's not right for Debian
to support that use case, that's fine.

> > Using Recommends for non-core parts of
> > metapackages' dependencies would nicely solve that.
>
> ...but I disagree that making meta-packages more elastic is a "nice"
> solution: is a hack covering over misguided users. Possible solutions
> could be improved documentation and improved design of package managers.

... And I disagree with that. No solution can override policy's "all
Depends must be satisfied". If one choose to support the "exclude from
metapackage" one either has to change the policy, remove packages from
Depends or use non-stock metapackage (which I personally don't like).

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


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120710190710.GD5107@r500-debian

[Noel David Torres Taño]

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

[...]

>

> Well, in case of GNOME, upstream considers n-m to be part of the core

> system, to the best of my knowledge. If upstream does so, so should we.

 

No. That's why we have our own distribution instead of just a collection of unpatched packages compiled from source.

 

Debian patches do not only include security or functionality bugs. They include also design bugs.

 

Regards

 

Noel Torres

er Envite

[Noel David Torres Taño]

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

[...]

> "Recommends

>

> This declares a strong, but not absolute, dependency.

>

> The Recommends field should list packages that would be found together

> with this one in all but unusual installations."

 

...packages that would be found together with this one in _all_ but unusual installations.

 

I think this is exactly the relationship between gnome and n-m: they are found together in all but unusual (e.g. people that manages their own interfaces, and that is not strange, but also not the majority of debian user base) installations.

[Andrei POPESCU]

On Ma, 10 iul 12, 22:07:10, Eugene V. Lyubimkin wrote:
>
> ... And I disagree with that. No solution can override policy's "all
> Depends must be satisfied". If one choose to support the "exclude from
> metapackage" one either has to change the policy, remove packages from
> Depends or use non-stock metapackage (which I personally don't like).

One solution proposed some time ago was to have package managers mark
packages depended on as manually installed, whenever the user choses to
uninstall only one package depended by meta-pacakge.

IMVHO Recommends makes more sense for packages that are not strictly
required, but maybe package managers should gain a
"Install-New-Recommends" option defaulting to true?

[Eugene V. Lyubimkin]

On 2012-07-10 22:21, Andrei POPESCU wrote:
> On Ma, 10 iul 12, 22:07:10, Eugene V. Lyubimkin wrote:
> >
> > ... And I disagree with that. No solution can override policy's "all
> > Depends must be satisfied". If one choose to support the "exclude from
> > metapackage" one either has to change the policy, remove packages from
> > Depends or use non-stock metapackage (which I personally don't like).
>
> One solution proposed some time ago was to have package managers mark
> packages depended on as manually installed, whenever the user choses to
> uninstall only one package depended by meta-pacakge.

Which leads to

a) manual bookkeeping if I decide to remove rest of metapackage's
dependencies later;
b) if later the metapackage in the repository adds/removes dependencies,
it isn't reflected at all in my system.

> IMVHO Recommends makes more sense for packages that are not strictly
> required

Right, that's how they are defined in policy.

> but maybe package managers should gain a
> "Install-New-Recommends" option defaulting to true?

Recommends are installed by default for quite a time already.

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


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120710193859.GF5107@r500-debian

[Gergely Nagy]

Nikolaus Rath <Niko...@rath.org> writes:

> Gergely Nagy <alge...@balabit.hu> writes:
>> But, to cut the story short, attached to this mail is a script you can
>> use to take any metapackage, and remove (or demote) any of its
>> dependencies. It echoes a control-file thingy, combining it with equivs
>> is left as an excercise to the reader.
>
> If I'm not mistaken, that means that the demoted dependency will get
> pulled in again on the next upgrade of the metapackage, or that I have
> to put the metapackage on hold and will loose any demotions and
> promotions of other packages in future metapackage versions.

No, you name the local meta package differently. No need to put it on
hold or anything. If you want to follow the original meta, set things up
so that the local gets updated once in a while.

That's doable with an Apt::Update::Post-Invoke hook, as I believe I said
in the mail above.

--
|8]

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87pq834...@luthien.mhp

[Gergely Nagy]

Nikolaus Rath <Niko...@rath.org> writes:

> Gergely Nagy <alge...@balabit.hu> writes:
>> For the cases where one wants to have most of the stuff installed that
>> the meta-package would pull in, but not all, solutions already exist.
>
> What solutions do you mean?

Installing the pieces one wants by hand, for one. Automating that with a
custom meta-package as another, using my script for the automation as a
third. Using equivs to create a dummy stub for the unwanted packages
(eg, n-m) and using the meta package as-is as a fourth.

There are probably other, similarly straightforward options, but four's
enough for a start.

--
|8]

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87liir4...@luthien.mhp

[Jonas Smedegaard]

...and our own distribution consist of multiple packages, some of which
may happen to match upstream.

It is a feature (which each user is free to avoid by not using it!) for
Debian to include a meta-package that pulls in that eeeevil n-m, not a
bug.


- Jonas

...who dislikes GNOME and network-manager but sometimes use the latter

[Jonas Smedegaard]

On 12-07-10 at 10:07pm, Eugene V. Lyubimkin wrote:
> On 2012-07-10 20:15, Jonas Smedegaard wrote:
> > On 12-07-10 at 07:35pm, Eugene V. Lyubimkin wrote:
> > > On 2012-07-10 18:10, Jonas Smedegaard wrote:
> > > > The very purpose of a meta-package is to _ensure_ that a certain
> > > > set of packages is installed, not just recommend them: All (not
> > > > only most) users of that package need all its dependencies
> > > > satisfied
> > >
> > > My definition of meta-package is less strict than yours. I as user
> > > sometimes want '[meta]package X, but without packages Y and Z',
> > > and your definition absolutely rules that out.
> > >
> > > I saw many questions on forums like
> > >
> > > "I did '$packagemanager install $metapackage' and then after
> > > '$packagemanager remove $singlepackage', why $packagemanager now
> > > wants to remove all $metapackage?"
> > >
> > > , so I know I'm not alone.
> >
> > [...]
> > You being alone does not make you right.
> >
> > A package manager wanting to remove all dependencies of a
> > meta-package is quite sensible - when you understand the sense of
> > it. Until then it is utterly confusing.
>
> As someone who developed a high-level package manager for Debian from
> scratch (including the autoremoval functionality) I'm pretty sure I
> understand the sense of it.

Fair enough. Sourry if it sounded like I was talking down to you, that
wasn't my intention. I simply meant to acknowledge that users can be
confused - I sure have been (and problably still is about some things,
time will - hopefully - tell).

> My message was: users who don't (yet) understand the full picture,
> find that behavior confusing, and it takes time to explain. Moreover,
> despite me understanding the picture, I still has no clean, safe and
> documented way to do what I'd want in case the package maintainer
> chosed Depends.

Acknowledged.

> Next, I don't pretend I'm "right", I do pretend there are >= 1 person
> who don't need all dependencies of the metapackage installed, and
> hence your 'All [...] users of that package need all its dependencies
> satisfied' clause is wrong. You can argue that it's not right for
> Debian to support that use case, that's fine.

I do support the use case of not needing all packages depended on by
some meta-package.

My point was (and still is) that those should not use that meta-package:
The users of a meta-package is the users of what the meta-package does,
which is to pull in a certain set of other packages.

It might very well be that some other meta-packages has the different
purpose of only _recommending_ a set of packages, but evidently this one
does not.

No, I do not find it right for Debian to mandate meta-packages to only
recommend when some users need only a subset of the offerings of said
meta-package: There will _always_ be some users needing only a subset of
things, rendering all dependencies "wrong" by that logic!

(...as has already been pointed out by others)

> > > Using Recommends for non-core parts of metapackages' dependencies
> > > would nicely solve that.
> >
> > ...but I disagree that making meta-packages more elastic is a "nice"
> > solution: is a hack covering over misguided users. Possible
> > solutions could be improved documentation and improved design of
> > package managers.
>
> ... And I disagree with that. No solution can override policy's "all
> Depends must be satisfied". If one choose to support the "exclude from
> metapackage" one either has to change the policy, remove packages from
> Depends or use non-stock metapackage (which I personally don't like).

You need not redefine "depends" to not mean "depends": Simply do not use
that meta-package if you do not want _all_ its dependencies installed.

[Andrei POPESCU]

On Ma, 10 iul 12, 22:38:59, Eugene V. Lyubimkin wrote:
> On 2012-07-10 22:21, Andrei POPESCU wrote:
>
> > but maybe package managers should gain a
> > "Install-New-Recommends" option defaulting to true?

^^^^^

> Recommends are installed by default for quite a time already.

Sure, but not new ones :)

[Jonathan Nieder]

Hi,

Jonas Smedegaard wrote:

> No, I do not find it right for Debian to mandate meta-packages to only
> recommend when some users need only a subset of the offerings of said
> meta-package: There will _always_ be some users needing only a subset of
> things, rendering all dependencies "wrong" by that logic!

Now hold on a second.

I don't think Eugene would advocate any such sweeping principle as the
one described above. One thing he did say is that he is against is a
magic "metapackages" section transforming Depends into something
weaker. I imagine you'd agree with him about that.

So where is the point of disagreement here?

There is a danger in overgeneralizing too early. As far as I can
tell, the actual problem at hand is:

- The gnome-core metapackage is very useful to some people. It helps
people install a standard GNOME installation, keep it installed,
and remove it later if they wish, using a single package.

- Some of the same people do not want to have network-manager
installed. They also do not want to have network-manager
fake-installed using equivs because they want to notice if they try
to install something that actually requires network-manager.

Given the above problem description, using a Recommends in the
metapackage would seem like a pretty reasonable solution.

Unfortunately there is another complication that throws a spanner in
the works:

- Some higher-level package managers do not honor Recommends
correctly (I do not know the details of this and would love to see
a link to the relevant bug), and therefore the Debian GNOME
maintainers are very wary of using Recommends in their metapackages

See? Two reasonable perspectives. Nothing left to argue about.

I'd encourage anyone wanting to move forward to take all three items
listed above into account.

Hope that helps,
Jonathan

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120710214627.GA20337@burratino

[David Kalnischkies]

On Tue, Jul 10, 2012 at 10:53 PM, Andrei POPESCU
<andreim...@gmail.com> wrote:
> On Ma, 10 iul 12, 22:38:59, Eugene V. Lyubimkin wrote:
>> On 2012-07-10 22:21, Andrei POPESCU wrote:
>>
>> > but maybe package managers should gain a
>> > "Install-New-Recommends" option defaulting to true?
> ^^^^^
>
>> Recommends are installed by default for quite a time already.
>
> Sure, but not new ones :)

Oh really?

Then please tell me what this code does:
http://anonscm.debian.org/loggerhead/apt/debian-sid/annotate/head:/apt-pkg/depcache.cc#L1103

(and yes, minus refactoring and bugfixing, this code is older than the
switch to enable installation of recommends by default for lenny …)


Now, you might as well talk about other package managers, but if so,
please be specific so that a problem can be fixed rather than talked
about every two years in a thread about what should be installed by
default or not in a very unspecific "doesn't work at all" way.

It is enough if we talk in that style about the package in question,
we don't need to extend that style to everything else in the thread …
(I wouldn't mind if we would stop talking in that style at all, but I
don't use n-m, so in that specific case, I don't care …)


Best regards

David Kalnischkies, who doesn't know whether to
laugh or cry about these kind of threads …

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CAAZ6_fDTAydt1UBp08yf0d8L...@mail.gmail.com

[Ivan Shmakov]

>>>>> Jonas Smedegaard <d...@jones.dk> writes:

[…]

> It is a feature (which each user is free to avoid by not using it!)
> for Debian to include a meta-package that pulls in that eeeevil n-m,
> not a bug.

… And what exactly this “feature” gives to the user?

[…]

--
FSF associate member #7257 http://sf-day.org/

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/86d3430...@gray.siamics.net

[Andrei POPESCU]

On Mi, 11 iul 12, 00:08:18, David Kalnischkies wrote:
>
> Then please tell me what this code does:
> http://anonscm.debian.org/loggerhead/apt/debian-sid/annotate/head:/apt-pkg/depcache.cc#L1103
>
> (and yes, minus refactoring and bugfixing, this code is older than the
> switch to enable installation of recommends by default for lenny …)

Sorry, I should know better than to talk about things I don't have
direct experience with :(

[Jonas Smedegaard]

On 12-07-11 at 10:04am, Ivan Shmakov wrote:
> >>>>> Jonas Smedegaard <d...@jones.dk> writes:
>
> […]
>
> > It is a feature (which each user is free to avoid by not using it!)
> > for Debian to include a meta-package that pulls in that eeeevil
> > n-m, not a bug.
>
> … And what exactly this “feature” gives to the user?

The single feature that makes anyone want to install the package:

On 12-07-10 at 06:10pm, Jonas Smedegaard wrote:
> The very purpose of a meta-package is to _ensure_ that a certain set
> of packages is installed, not just recommend them: All (not only most)

> users of that package need all its dependencies satisfied - those that
> don't should simply uninstall the meta-package.

Some argue that meta-packages can have a different purpose, and some
argue that recommending also to some (lesser) extend ensures
installation of packages. None of that, however, changes the fact that
_this_ meta-package _now_ has the feature of strictly ensuring a certain
set of packages. For those wanting that. And not for those feeling it
is in their way, but those can simply avoid that package: A meta-package
has no functionalirty beyond pulling in packages, so there is no loss to
the resulting system other than lack of its sole feature.


- Jonas

[Andrei POPESCU]

On Mi, 11 iul 12, 09:10:12, Jonas Smedegaard wrote:
> A meta-package has no functionalirty beyond pulling in packages, so
> there is no loss to the resulting system other than lack of its sole
> feature.

IMVHO a feature almost as important is to remove a set of packages.

[Jonas Smedegaard]

On 12-07-11 at 10:45am, Andrei POPESCU wrote:
> On Mi, 11 iul 12, 09:10:12, Jonas Smedegaard wrote:
> > A meta-package has no functionalirty beyond pulling in packages, so
> > there is no loss to the resulting system other than lack of its sole
> > feature.
>
> IMVHO a feature almost as important is to remove a set of packages.

The feature of _removing_ a set of packages: "aptitude remove ..."

The feature of _ensuring_ a set of packages is not installed: Make a
meta-package that conflicts with the packages.

The feature of _allowing a subset of packages to be removed that was
_ensured_ to be installed: Impossible without defeating the feature of
_ensuring_ those same package are installed.

[Josselin Mouette]

Le mardi 10 juillet 2012 à 20:01 +0200, Jonas Smedegaard a écrit :
> I disagree: Looking at the many other dependencies of gnome-core, it
> clearly isn't meant as "smallest possible GNOME setup" but more
> "essential parts of what the upstream GNOME project has to offer" - as
> its package description also clearly reflects.
>
> When I want "smallest possible GNOME setup" i install gnome-session.

Yes, maybe we should advertise it more, but gnome-session should be
self-contained, and enough for a bare GNOME desktop without any
applications.

--
.''`. Josselin Mouette
: :' :
`. `'
`-

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/1341998092.10559.132.camel@pi0307572

[Andrei POPESCU]

On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote:
>
> The feature of _allowing a subset of packages to be removed that was
> _ensured_ to be installed: Impossible without defeating the feature of
> _ensuring_ those same package are installed.

Agreed. However, unless I missed something I haven't seen any arguments
for why gnome-core really needs to _ensure_ that network-manager-gnome
is installed, other than "upgrade issues" without any other details.

[Andrei POPESCU]

On Mi, 11 iul 12, 11:14:52, Josselin Mouette wrote:
>
> Yes, maybe we should advertise it more, but gnome-session should be
> self-contained, and enough for a bare GNOME desktop without any
> applications.

Yes please :)

Some kind of harmonization of (meta-)package names with KDE would also
be very nice. As far as I can tell, currently the equivalence would be:

??? kde-full
gnome kde-standard
gnome-core kde-plasma-desktop/kde-plasma-netbook
gnome-session ???

(probably too late for wheezy, but maybe this could be done for
wheezy+1)

Thanks,

[Jonas Smedegaard]

On 12-07-11 at 12:12pm, Andrei POPESCU wrote:
> On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote:
> >
> > The feature of _allowing a subset of packages to be removed that was
> > _ensured_ to be installed: Impossible without defeating the feature
> > of _ensuring_ those same package are installed.
>
> Agreed. However, unless I missed something I haven't seen any
> arguments for why gnome-core really needs to _ensure_ that
> network-manager-gnome is installed, other than "upgrade issues"
> without any other details.

Package description isn't enough argument?

> This meta-package depends on a basic set of programs, including a file
> manager, an image viewer, a web browser, a video player and other
> tools.
>
> It contains the official “core” modules of the GNOME desktop.


I still (as previously mentioned) believe that you really should focus
on gnome-session instead, if you feel gnome-core is too invasive when it
insist on installing certain image viewer, web browser, video player and
"other tools" (which includes a certain network manager).

[Thibaut Paumard]

Le 11/07/12 11:14, Josselin Mouette a écrit :

> Le mardi 10 juillet 2012 à 20:01 +0200, Jonas Smedegaard a écrit :
>> I disagree: Looking at the many other dependencies of gnome-core, it
>> clearly isn't meant as "smallest possible GNOME setup" but more
>> "essential parts of what the upstream GNOME project has to offer" - as
>> its package description also clearly reflects.
>>
>> When I want "smallest possible GNOME setup" i install gnome-session.
>
> Yes, maybe we should advertise it more, but gnome-session should be
> self-contained, and enough for a bare GNOME desktop without any
> applications.
>

Indeed, I think it would be good if the three meta-packages gnome,
gnome-core and gnome-session would advertise each other in their long
description.

Regards, Thibaut.

[Claudius Hubig]

Andrei POPESCU <andreim...@gmail.com> wrote:
>??? kde-full
>gnome kde-standard
>gnome-core kde-plasma-desktop/kde-plasma-netbook
>gnome-session ???

Maybe some sort of renaming would also be nice to make the
‘hierarchy’ more obvious? Along the lines of

??? kde-full *-full
gnome kde-standard *-most
gnome-core kde-plasma-desktop *-mini or *-small
gnome-session ??? *-micro or *-minimal

Everybody can see that micro < mini and full > *, but if you asked two
people whether ‘core’ or ‘session’ were ‘larger’, you’d probably get
three answers.

The wording above is arguably improvable, though.

Best regards & thank you very much,

Claudius

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120711115...@ares.home.chubig.net

[Sune Vuorela]

On 2012-07-11, Andrei POPESCU <andreim...@gmail.com> wrote:
>
> --YZa61AII3s1sGKYx
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable

>
> On Mi, 11 iul 12, 11:14:52, Josselin Mouette wrote:

>>=20

>> Yes, maybe we should advertise it more, but gnome-session should be
>> self-contained, and enough for a bare GNOME desktop without any
>> applications.
>
> Yes please :)
>

> Some kind of harmonization of (meta-)package names with KDE would also=20

> be very nice. As far as I can tell, currently the equivalence would be:
>
> ??? kde-full
> gnome kde-standard
> gnome-core kde-plasma-desktop/kde-plasma-netbook
> gnome-session ???

I'd rather put kde-plasma-desktop/kde-plasma-netbook on the
gnome-session level. and probably kde-full at the gnome level.
kde-standard is not a collection by upstream, but a collection by the
debian people, so it doesn't fully fit the gnome-core.

/Sune

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/slrnjvqkm8...@sshway.ssh.pusling.com

[Jon Dowland]

On Tue, Jul 10, 2012 at 04:39:10PM +0000, Sune Vuorela wrote:
> On 2012-07-10, Gergely Nagy <alge...@balabit.hu> wrote:
> > No. Only if installing recommends is turned on, which cannot be
> > guaranteed.
>
> There is many ways to break your system. turning off installation of
> recommends is one of them.

If turning off recommends leads to a broken system, then there's a serious
bug somewhere, and it isn't the user.

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20120711103854.GA11211@debian

[Andrei POPESCU]

On Mi, 11 iul 12, 10:17:44, Sune Vuorela wrote:
>
> I'd rather put kde-plasma-desktop/kde-plasma-netbook on the
> gnome-session level. and probably kde-full at the gnome level.
> kde-standard is not a collection by upstream, but a collection by the
> debian people, so it doesn't fully fit the gnome-core.

I went by package descriptions, the same as a (new) Debian user might
do.

Kind regards,

[Henrique de Moraes Holschuh]

On Tue, 10 Jul 2012, Andrei POPESCU wrote:
> On Ma, 10 iul 12, 22:07:10, Eugene V. Lyubimkin wrote:
> > ... And I disagree with that. No solution can override policy's "all
> > Depends must be satisfied". If one choose to support the "exclude from
> > metapackage" one either has to change the policy, remove packages from
> > Depends or use non-stock metapackage (which I personally don't like).
>
> One solution proposed some time ago was to have package managers mark
> packages depended on as manually installed, whenever the user choses to
> uninstall only one package depended by meta-pacakge.

Wow, that'd be a very poor way to break the system further in order to make
meta-packages even more annoying.

IMO, metapackages should "depend" on the absolutely required stuff (and many
times that will be the empty set), "recommend" the rest, and maybe even
"suggest" fringe packages. This achieves maximum usability for more
usecases, and malfunctions only in the unsupported case of "no install
recommends by default" -- you should skip recommends always in a
case-by-case basis.

> IMVHO Recommends makes more sense for packages that are not strictly
> required, but maybe package managers should gain a
> "Install-New-Recommends" option defaulting to true?

Package managers already disclose that sort of relationship (sometimes
indirectly). I've been using that information for years through aptitude.

OTOH, metapackages from hell (like gnome or kde-full) based on Depends
require me to select them, go to the "will install these" screen, deselect
the meta package, and go over the list manually installing whatever isn't
going to be useless/unwelcome for my specific case. And I will never notice
if the metapackage changes its dependency tree later on. The only reason I
have to do it in this extremely suboptiomal way, is the (IMO) abuse of
"Depends" on metapackages instead of a much more proper mix of mostly
"recommends", with sparingly used "depends" and "suggests" when the
situatuion warrants it.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012071111...@khazad-dum.debian.net

[Henrique de Moraes Holschuh]

On Wed, 11 Jul 2012, Jon Dowland wrote:
> On Tue, Jul 10, 2012 at 04:39:10PM +0000, Sune Vuorela wrote:
> > On 2012-07-10, Gergely Nagy <alge...@balabit.hu> wrote:
> > > No. Only if installing recommends is turned on, which cannot be
> > > guaranteed.
> >
> > There is many ways to break your system. turning off installation of
> > recommends is one of them.
>
> If turning off recommends leads to a broken system, then there's a serious
> bug somewhere, and it isn't the user.

Broken as in "partially working because there are expected features missing"
is the _very_ definition of "not installing a recommended package".

Now, "broken" as in "doesn't work at all for any use case" would be a bug,
yes.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012071111...@khazad-dum.debian.net

[Jean-Christophe Dubacq]

On 11/07/2012 11:12, Andrei POPESCU wrote:
> On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote:
>>
>> The feature of _allowing a subset of packages to be removed that was
>> _ensured_ to be installed: Impossible without defeating the feature of
>> _ensuring_ those same package are installed.
>
> Agreed. However, unless I missed something I haven't seen any arguments
> for why gnome-core really needs to _ensure_ that network-manager-gnome
> is installed, other than "upgrade issues" without any other details.

If my memory does not fail me, support from upstream (since
network-manager is a core component of Gnome). I may be wrong.

Sincerly,
--
Jean-Christophe Dubacq

[Andreas Beckmann]

On 2012-07-10 23:46, Jonathan Nieder wrote:
> - The gnome-core metapackage is very useful to some people. It helps
> people install a standard GNOME installation, keep it installed,
> and remove it later if they wish, using a single package.

Most metapackages provide such a "useful collection of packages" (that
may evolve over time). They usually provide alternative implementations
of some functionality that don't conflict with each other (e.g. desktop
environment: Gnome/KDE/Xfce/... (disregarding n-m for now), editor:
vim/emacs/..., typesetting: texlive/libreoffice/...). Some have a subset
relation: foo-core -> foo-standard -> foo-full
If the metapackage depends on an application you don't like, you just
don't use it and install another one. Usually the unused one won't do
harm by just being installed. (If you were really concerned about disk
space you wouldn't use the metapackages but install only the things you
use (and create your own minimized metapackages).)

The situation with n-m is a bit different: the functionality it provides
*conflicts* with alternative solutions (which were previously enumerated
in this thread) and there is (afaik) no switch to just turn n-m off to
allow using $alternative while keeping n-m installed.

> - Some of the same people do not want to have network-manager
> installed. They also do not want to have network-manager
> fake-installed using equivs because they want to notice if they try
> to install something that actually requires network-manager.

This functionality *conflict* is the reason several people (including
me) would like to see that dependency downgraded to a Recommends.

And if there are bugs in handling Recommends properly, they should be fixed.

Andreas

--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/4FFD7441...@abeckmann.de