On 11 July 2012 14:21, Noel David Torres Taño <envite@rolamasao.org> wrote:
> Installing N-M breaks unrelated software.

Hi!

I don't claim to be a networking expert, but I believe half the
conversation here is based on wrong or outdated information. I
encourage those who think NetworkManager (NM) doesn't play well with
ifup/ifdown to please read
http://wiki.debian.org/NetworkManager#NetworkManager_in_Squeeze

Furthermore, not having NM running breaks the Network panel in System
Settings (gnome-control-center).

NetworkManager makes connecting to WiFi points much much easier, while
at the same time NOT breaking wired connectivity. Oh, and NM works
just fine for USB tethering with my Android phone too.

GNOME considers NM to be part of GNOME Core, therefore gnome-core
depends on it. If you're allergic to NM, either don't install
gnome-core; let NM install but tell it never to run; or follow one of
the several workarounds already posted to this list.

Thanks,
Jeremy


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAajCMZvRd2m1RiQq51pXpCa0zuey-ELUvChCzQt0MMzrW3iMw@mail.gmail.com">http://lists.debian.org/CAAajCMZvRd2m1RiQq51pXpCa0zuey-ELUvChCzQt0MMzrW3iMw@mail.gmail.com

On Wed, Jul 11, 2012 at 08:04:18PM -0400, Jeremy Bicha wrote:
> On 11 July 2012 14:21, Noel David Torres Taño <envite@rolamasao.org> wrote:
> > Installing N-M breaks unrelated software.
>
> I don't claim to be a networking expert, but I believe half the
> conversation here is based on wrong or outdated information. I
> encourage those who think NetworkManager (NM) doesn't play well with
> ifup/ifdown to please read
> http://wiki.debian.org/NetworkManager#NetworkManager_in_Squeeze

The information on that page is outdated, then.

On my system for example, it shows eth0 as unmanaged (correctly) but puts
its grubby mitts into br0 and usb0, both of which are listed in
/etc/network/interfaces.

Being "unmanaged" also makes it think the interface is down.


Also, the page you linked to includes this line:
# understand that NetworkManager is not intended to serve the needs of all
# users
So if n-m is not supposed to be universal, it must not prevent people from
doing things not supported by it, either by standing aside or being
uninstallable.

> Furthermore, not having NM running breaks the Network panel in System
> Settings (gnome-control-center).

It makes it give an error message. This is the only regression, and it
really should check the presence of NM instead of blindly show that icon.
Even then, it's not a show stopping bug. And getting rid of a
non-functional icon from the systray is worth having another in some
section of a settings panel (even if I'd prefer having neither).

> NetworkManager makes connecting to WiFi points much much easier

Which is related to it messing with interfaces other than WiFi... how?

> while at the same time NOT breaking wired connectivity.

We wouldn't have this long thread if it indeed did not break it.

> Oh, and NM works just fine for USB tethering with my Android phone too.

Not for mine (N900) nor my brother's (some Android, can't check until he
visits again). NM recognizes it as "Nokia N900" but tries to configure it
despite being told not to, and it keeps resetting it every a few seconds
so you can't fix it up manually.

> GNOME considers NM to be part of GNOME Core, therefore gnome-core
> depends on it.

It also wants systemd and mono, yet on Debian you can install without
either.

> If you're allergic to NM, either don't install gnome-core;

Gnome has enough components to make installing it without help of meta
packages an unreasonable idea for anyone not deeply involved with Gnome
development. And we're talking about "-core" not "all bells and whistles".

> let NM install but tell it never to run

The last time I tried, /etc/resolv.conf became:
"# Generated by NetworkManager

".

This is also inventing a way around dependencies: if a daemon is not
supposed to be ever run, it shouldn't be installed in the first place,
otherwise the packaging system has no way to specify actual requirements.

> or follow one of the several workarounds already posted to this list.

You mean, using dpkg --force-depends and not using apt at all? Or making my
own equivs metapackage (which I can do but most users can't)?

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

On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote:
> Installing N-M breaks unrelated software.

No. At most it breaks *related* software.

Kind regards
Philipp Kern

On Wed, Jul 11, 2012 at 09:32:19PM -0600, Philipp Kern wrote:
> On Wed, Jul 11, 2012 at 07:21:00PM +0100, Noel David Torres Taño wrote:
> > Installing N-M breaks unrelated software.
>
> No. At most it breaks *related* software.

Exactly, that's why it's the "gnome-core" package that's RC-buggy, not
network-manager. Unless someone thinks a desktop environment's core
function is to mess with the network, that is.


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

Le mercredi 11 juillet 2012 Ã* 19:17 +0100, Noel David Torres Taño a
écrit :
> So a meta-package is "just" a way of installing things together, and a
> lot more. But from those things, only dependencies should be Depends,
> and software that improves the collection should be Recommends. In
> this particular case, N-M improves gnome but it is not needed at all.

By the same view, totem improves GNOME, but it is not needed at all.
Gcalctool improves GNOME, but it is not needed at all.
Here’s the point: those packages are *part* of GNOME. And that includes
nm-gnome, too.

If you want only the required components, install gnome-session.
Everything else is “improvement�.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1342077817.10559.183.camel@pi0307572

On 2012-07-12 09:23, Josselin Mouette wrote:
> By the same view, totem improves GNOME, but it is not needed at all.

Correct. But it does not conflict with kaffeine, mplayer, vlc, xine, ...

> Gcalctool improves GNOME, but it is not needed at all.

Correct. But it does not conflict with bc, kcalc, ...

> Here’s the point: those packages are *part* of GNOME. And that includes
> nm-gnome, too.

But it does *conflict* with the alternatives.

Debian's horizon extends far beyond 'just Gnome'.


Andreas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FFE8397.1090902@abeckmann.de">http://lists.debian.org/4FFE8397.1090902@abeckmann.de

On Wed, 2012-07-11 at 23:57 +0200, Cyril Brulebois wrote:
> Noel David Torres Taño <envite@rolamasao.org> (11/07/2012):
> > > Your view is irrelevant here: GNOME project considers it essential.
> >
> > Gnome view is the one irrelevant. This is Debian GNU/Linux, not Gnome
> > GNU/Linux. We need to care for our users (both proficient and novice [1]),
> > not for Gnome developers desires. And if they had a flawed design we can
> > patch, we should do as we do with any other flawed software.
>
> Blah blah blah. What matters is the maintainers' views (as long as
> common sense applies). They chose to follow upstream's choices, which is
> usually a sane thing to do (unless upstream is crazy).
If Gnome core are really convinced that NM is essential, why Gnome could
be run without NM? Why not all Gnome applications are depending on NM
for network detection? Why the applications that depends on NM like
evolution have all a fall-back mode?

I'm maintaining a package which upstream delivers as all in one (600MB)
and refuses to support splitting. I've split it into 22 packages because
I know and got requests from users who want to have it in machines with
small disks and/or low internet.
Upstream never accepted that, but I didn't gave up, because what matters
for me is user not upstream

> Now if you don't like those choices, pick your own packages yourself,
> build your own meta package, or whatever.
An push it to repository? Then Yes I can upload a
gnome-desktop-workstation package to be used for atypical users like me

> Plenty of RC bugs to submit patches for. Surely more interesting than
> those meta packages, right?
I'm not interested in patching Gnome myself, I'm a user, not a gnome
maintainer/developer

Cheers,

Noel David Torres Taño <envite@rolamasao.org> writes:

>> Yet, we try to not diverge much from upstream, and maintain a good
>> relationship with them. If they consider it core, so can we. Those who
>> want to hand-pick parts of a meta package, can do so, we do not forbid.
>
> If we want to be user friendly, it is not a matter of "we do not forbid", it
> is a matter of "we make easy". Besides, low-level users will install
> Recommends by default, so they will get the whole box anyway. But medium or
> high level users may probably want N-M not to mess their network EVEN if they
> want the whole gnome desktop set.
>>
>> I do not see the problem: those who want the full platform, can get it
>> easily. Those who don't, and want to exclude some, they can do so easily
>> too. A bit more work, but hey, if you're going to cherry pick, that will
>> always involve more work.
>>
>> The amount of extra work necessary is minimal though.
>
> Not so minimal if you want your gnome set to be up to date, including new
> applications being installed.

It is very minimal. 5 minutes of work. Been there, done that, posted the
bulk of the solution, and a general outline of the rest of it to this
list, in this very thread, multiple times.

Please take some time to read it. But alas, I'll make it easy for you:

If you want to install a meta-package, but without one of its
dependencies, and want to keep up to date with it too, so you get all
the new stuff added to it, and you also want to be able to remove the
whole thing with one swift sweep, here's what you do:

- Grab the control file of the meta-package
(~1 line in shell, use grep-aptavail)
- Filter out unwanted packages from depends
(~5-6 lines in shell)
- Create a local package, under a different name, with the updated
information
(~10-20 lines, use equivs)
=== 5 minutes so far ===
- Push it into a local repository
(~2-3 lines, use whatever, reprepro, mini-dinstall, or cat <<EOF)
- Put the local repo in sources.list
- apt-get update & install your shiny new meta-package
- Hook all that into Apt::Update::Post-invoke

That's it. The whole thing is under a hundred lines, and easily doable
within half an hour (for the record, I implemented all of the above this
morning in 17 minutes while still half asleep).

If you want to be super-cool, create a sourcable config file that tells
the generator script what packages to filter out from which metas. Pack
it up, ship a deb, everyone's happy.

Even better, here's an alternative solution:

- Grab a list of unwanted packages
- Create a dummy package with an epoch of 99, using the same name the
unwanted packages.
- Install them
- Use the meta-package unmodified

(Whole excercise doable in 10 minutes tops, including reading the equivs
documentation.)

All of that took a fraction of the time than arguing here on this list,
about things that can already be solved *conveniently* by anyone caring
enough, in multiple ways. Obviously, most people in this thread don't,
as we'd already have a packaged solution if that weren't the case.

And since noone seems to have cared enough to come up with a solution
that works for *everyone* (upstream, novice and advanced users alike,
and maintainers too), can we drop the subject now?

> What we should do is to allow TWO levels of cherry-picking: the one for
> advanced users who want to individually select every package, and the other
> for users who want the whole set without a specific, molesting package.

We already have the first, it's called installing by hand. The second
can easily be done, see above.

> If that package is not a true dependency of the core of the set,
> Recommends is more than justified.

Upstream considers it a dependency in this case, part of a
platform. If you don't want the full platform, don't install the full
one, select the pieces you need - it is that easy.

Similarly, if you don't want to install a full blown desktop system with
a GUI, you don't select the desktop task when installing Debian. If you
do want some little things later, you install those by hand.

In case of gnome, the package pulls together what upstream considers the
GNOME platform - it is that simple. If you don't need it all, don't
install it all. If you want to follow the platform, but skip parts of
it, I already presented two solutions above.

You're welcome.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87hatdv0dm.fsf@algernon.balabit

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

> On 2012-07-11 14:33, Gergely Nagy wrote:
>> "Eugene V. Lyubimkin" <jackyf@debian.org> writes:
>>
>> > 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.
>>
>> You have: install the pieces you want by hand. That's at least clean and
>> safe. I do not think it is worth documenting explicitly.
>
> No, this is (IMO) not a solution: [1]

Script it. I believe those who are unhappy with n-m, and understand what
Depends and Recommends do, are able to write 20 lines of shell.

I already posted at least one solution for the problem:
https://lists.debian.org/debian-devel/2012/07/msg00219.html

>> [...] Demoting to Recommends would be
>> less so, but if upstream considers a package a core part of a platform,
>> recommends *is* wrong. If you disagree with upstream, you have the tools
>> and the ability to customize your system: use a non-stock meta package.
>
> Well, disagreed here. By the logic above we, for example, cannot apply
> any patches NACKed by upstream.

That's not nearly the same thing.

>> It's not hard. I'd be very curious why you're so against it, perhaps we
>> can come up with a solution that satisfies you?
>
> Because if a user who installed Debian yesterday asks me "So how do I do
> that?" I want my answer to be
>
> "It's easy, just do '$packagemanager remove $singlepackage'"
>
> instead of
>
> "It's easy, just build and maintain a non-stock meta package"

How about: "Install $this package, and run $that command, answer its
questions, and you're done!"

That would:
- Allow us to keep Depends as Depends
- Allow users who wish to follow the meta, with parts of it removed to
do so, conveniently.
- Leave everyone else unaffected.

Which, in turns means:
- People happy with the status quo remain happy
- People unhappy with have an easy, convenient solution that anyone can
use without knowing a thing about meta packages or building packages or
anything like it. A solution you could point a novice user to, and said
user would be happy with it.

Said package takes half an hour to make, perhaps another half to make it
friendly.

Those caring enough, could've solved the issue by now. Since there was
nothing done but useless throwing of words, I'd think noone cares
enough.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87d341uzsa.fsf@algernon.balabit

Steve McIntyre <steve@einval.com> writes:

> Gergely wrote:
>>Henrique de Moraes Holschuh <hmh@debian.org> writes:
>>
>>> 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.
>>
>>That also achives maximum annoyance, because if I want the full
>>platform, I'll have to go recommends/suggest hunting. (No, I'm *not*
>>going to turn on install-recommends.)
>
> Right. So you're arguing that all the packages should be listed as
> Depends: to make *your* life easier, when you're doing something
> different from what's recommended. Thanks for showing how much weight
> we should attach to your argument.

It's a meta-package, that pulls in a platform. If I install it, I want
the full platform, always. That's about it. If I install mono-complete,
I want the whole bloody thing, always. If I install kde-full, I want the
full KDE desktop, with all bells and whistles. If I install gnome, I
want the whole thing with all strings attached. That's what I consider a
meta-package's job.

If I want parts of it, I will install parts of it. Metas are a
convenience for the most common case: installing all of it.

Lets consider another case! Suppose I have Install-Recommends turned on,
and install a theoretical meta package, that has half of its stuff in
recommends, because they're not strictly necessary, but merely enhance
the system. Lets suppose one of these enhancements include a tool I use
every once in a while, but not daily.

Now, a few months later, a transition comes about, and this package I
have gets removed, because another thing I update
breaks/conflicts/whatevers it. Since it's a recommends only, my package
manager will most likely want to remove it.

I now have two options: I either notice this, and stop the upgrade, or I
don't and poof, part of the platform's gone. I installed the full thing,
and lost part of it. I'm not happy.

As for why I wouldn't notice? Because I trust the system to do the right
thing, and I do automatic, unattended upgrades. Not an uncommon thing to
do, I believe.

But with recommends, the system failed me here, and removed part of the
platform that I *explicitly* installed.

And I had Install-Recommends turned on.

Thank you, I'd rather have Depends, and a reliable way to keep the full
platform on my system. Would I want to remove parts of it, I already
have the power to do that with the status quo. I can even keep up with
the meta package easily, if I choose to do so.

I don't know about you, but I prefer my systems reliable and I
absolutely hate when it wants to screw me over and try to remove parts
of stuff I explicitly asked it to install.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87629tuz4v.fsf@algernon.balabit