aptitude dependency-resolver behaviors (was Re: apt-get install sysvinit-core removes gnome?)

2014-10-21 Thread The Wanderer
On 10/20/2014 at 11:59 AM, David Kalnischkies wrote:

 On Sun, Oct 19, 2014 at 09:32:54AM +0200, Matthias Urlichs wrote:
 
 David Kalnischkies:

 This isn't trying harder, it is trying increasingly incorrect
 solutions to the problem because aptitude assumes the users is
 not able to express himself correctly. apt-get is treating its
 user as its god instead, aka: user is always right, even if it
 makes no sense in apt's simple mind.
 
 My main problem is that, whenever I install a difficult package,
 the first solution I get presented is always to simply not install
 the package in question. The next 2^n-1 solutions transitively
 remove everything that currently conflicts with installing the
 thing in question. Rejecting the removal of a few core packages
 then gets me the correct solution, e.g. upgrading two packages.
 
 I think aptitude is calling this canceling actions. I would bet you
 can use this config setting to discourage it from doing that, but 
 ultimately its a design choice to allow or forbid them at all.
 
 Selecting one package in an or-group is a grand example of people
 not understand their tools although the policy is simple and
 logic: If it isn't impossible to let it win, the first
 alternative wins. If the package manager would go for any
 heuristic based on simplicity of installation instead everyone
 would have lsb-invalid-mta as MTA because that is damn easy to
 install by any standard. Maintainers are very heavily relying on
 this property while e.g. building packages.
 
 You don't have to drop that part of its logic. Choosing a different
 package as a dependency should of course be a last resort action
 (i.e. be heavily penalized). I'm not talking about changing that.
 I'm talking about the fact that aptitude treats upgrading to a
 slightly-lower-prioritized version of a package as a *way* worse
 solution than removing that package (and/or 500 others).
 
 Well, slightly lower priority means packages from a different
 release in general, so that isn't a safe action either. experimental
 and backports come to mind. Never upgrading to a security fix is
 another.
 
 Also – but that might be a relatively controversial point – users
 are much better at figuring out which packages they don't want
 removed compared to e.g. which packages should be held at a lower
 version, so I can optimize the other values and let the user decide
 along a property he can easily reason about (I am not suggestion that
 aptitude or apt-get work that way, but who knows that for sure
 anyway, right?).

What I think is being asked for (and what I'd certainly like to see,
anyway) is a way for the user, having figured out which packages they
don't want removed, to tell the aptitude resolver that and have it taken
into account in calculating a dependency solution.

As it happens, there's an obvious way to do that: specify the package(s)
you don't want removed on the aptitude command line.

However, one of the behaviors I've observed - which I think, per the
quote above, is part of exactly what is being complained about - is that
aptitude will often propose a solution which involves keep
package-X-from-command-line at its current version before proposing a
solution which involves install a new version of that same package.
Thus, specifying a package on the command line does not effectively tell
the aptitude resolver that you don't want it removed.

(I'm pretty sure I've seen a proposed solution, in a package-upgrade
scenario, which involved remove package X and everything that depends
on it, as well. But I don't recall any specifics on that one, so it
might be my imagination.)

My core objection to aptitude is less that it proposes non-optimal
solutions first (although that's certainly part of it) than that it
frequently, indeed perhaps consistently, proposes solutions which
involve *not doing the actual thing which was requested* before
proposing ones which do. That does not seem remotely reasonable, to me.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: aptitude dependency-resolver behaviors (was Re: apt-get install sysvinit-core removes gnome?)

2014-10-21 Thread Andrei POPESCU
On Ma, 21 oct 14, 09:08:26, The Wanderer wrote:
 
 What I think is being asked for (and what I'd certainly like to see,
 anyway) is a way for the user, having figured out which packages they
 don't want removed, to tell the aptitude resolver that and have it taken
 into account in calculating a dependency solution.
 
 As it happens, there's an obvious way to do that: specify the package(s)
 you don't want removed on the aptitude command line.

It's also possible to do it in interactive mode.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-20 Thread Andrei POPESCU
On Jo, 16 oct 14, 17:35:09, Martin Read wrote:
 
 mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
 Aptitude::ProblemResolver {
 SolutionCost priority, removals, canceled-actions;

I've had better (as in not unexpected) results with just 'removals'.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-20 Thread David Kalnischkies
On Sun, Oct 19, 2014 at 09:32:54AM +0200, Matthias Urlichs wrote:
 David Kalnischkies:
   Apitude, too, *really* likes to choose 500 deletions rather than upgrading
   even a single package to a version with slightly-lower priority (as 
   defined
   in /etc/apt/pref*), but at least you can tell it to try harder. :-/
  
  I shouldn't, I really shouldn't, but well, I bite…
  
  This isn't trying harder, it is trying increasingly incorrect solutions
  to the problem because aptitude assumes the users is not able to express
  himself correctly. apt-get is treating its user as its god instead, aka:
  user is always right, even if it makes no sense in apt's simple mind.
  
 My main problem is that, whenever I install a difficult package, the
 first solution I get presented is always to simply not install the package
 in question. The next 2^n-1 solutions transitively remove everything that
 currently conflicts with installing the thing in question. Rejecting the
 removal of a few core packages then gets me the correct solution, e.g.
 upgrading two packages.

I think aptitude is calling this canceling actions. I would bet you can
use this config setting to discourage it from doing that, but
ultimately its a design choice to allow or forbid them at all.


  Selecting one package in an or-group is a grand example of people not
  understand their tools although the policy is simple and logic: If it
  isn't impossible to let it win, the first alternative wins. If the
  package manager would go for any heuristic based on simplicity of
  installation instead everyone would have lsb-invalid-mta as MTA because
  that is damn easy to install by any standard. Maintainers are very
  heavily relying on this property while e.g. building packages.
 
 You don't have to drop that part of its logic. Choosing a different package
 as a dependency should of course be a last resort action (i.e. be heavily
 penalized). I'm not talking about changing that. I'm talking about the fact
 that aptitude treats upgrading to a slightly-lower-prioritized version of a
 package as a *way* worse solution than removing that package (and/or 500
 others).

Well, slightly lower priority means packages from a different release
in general, so that isn't a safe action either. experimental and
backports come to mind. Never upgrading to a security fix is another.

Also – but that might be a relatively controversial point – users are
much better at figuring out which packages they don't want removed
compared to e.g. which packages should be held at a lower version, so I can
optimize the other values and let the user decide along a property he can
easily reason about (I am not suggestion that aptitude or apt-get work
that way, but who knows that for sure anyway, right?).


 Basically, this boils down to the fact that people shouldn't have to read a
 manpage about a complex priority scheme in an equally-complex resolver.
 All I want is for aptitude to behave in a sane way by default.
 
 Its current behavior is not.

The usual approach to improving software is to whine about it on mailing
lists until its done. While this might work for init systems, it doesn't
for most stuff, so the better approach is helping to make it happen.

You even made the first step already by realising that the resolver is
indeed just as complex as the priority scheme – which can be described
in a few sentences. Most people regard them as ancient magic no living
human being understands. The irony is that this could very well be
a self-fulfilling prophecy as not that many people are left who work on
them…

(case in point: even with the dirty tricks I pulled to make MultiArch work
without too much pain, aptitude with its own solver was still more or less
broken by it. I guess I should have done a RoQA while I could… thankfully
a small new team materialized out of nowhere later on solving this problem.
The history of apt is equally fun to look at. We will see when Debian
finally run out of luck and does a RoQA ^apt.* I guess…)


Anyway, you want to talk about changes to aptitude to someone who is
actually into aptitude. aka: ¬me and I doubt you will find such
a person in a systemd related thread…


Best regards

David Kalnischkies


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-20 Thread David Kalnischkies
On Sun, Oct 19, 2014 at 01:34:13PM +0200, Holger Levsen wrote:
 cc:ing the apt maintainers to get their opinion on making this the default...

[Disclaimer: I have written the APT part of it. I might be biased.]

Hell no – as this isn't the point of the implementation. It is intended
to help researchers and developers alike to experiment with resolvers in
normal situations rather than fabricated snapshots as you can't jump
to conclusion about the greatness of a resolver based on one single
test – and experimentation is basically the opposite of what you would
want the default resolver be:
The multiple levels of indirection in the design are e.g. great for
playing, but horrible from a speed point of view. It would also move
a lot of stuff onto every debian system… I guess I don't have to tell
you what it means to pull in prio:extra packages from a build-essential
prio:important (and for all practical proposes nearly essential:yes)
package.

It's also not complete yet. The CUDF protocol for example learned very
recently what MutliArch is and how to not explode if its encountered,
I wouldn't exactly call this path exceptional well tested as a result.
[Disclaimer: I have written MultiArch in APT as well, so I flipped
between both for quiet a while… not fun, so biased again].

It isn't even clear yet which technique is strictly superior to what we
have at the moment as our naturally grown heuristic-solvers do pretty
well in real world scenarios. If you don't trust me on that:
http://mancoosi.org/~abate/package-managers-comparison-take-2 which
talks about http://www.mancoosi.org/measures/packagemanagers/2012/
[Disclaimer: I have written a lengthy comment there which should give
you a hint why I come to this conclusion … bias the third]

(And yes, while I consider it a bug that apt isn't able to figure this
one out without a little help, I don't really consider this case
an important realworld scenario. In the end, the times I will change
init systems is hopefully far below the GR proposal count for that.
Not only because I am lazy, but because it would mean that everyone
would have done a pretty crappy job making Debian jessie the best release
ever if no init works reliably [totally unbiased on this one] )


Best regards

David Kalnischkies


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-19 Thread Matthias Urlichs
Hi,

David Kalnischkies:
  Apitude, too, *really* likes to choose 500 deletions rather than upgrading
  even a single package to a version with slightly-lower priority (as defined
  in /etc/apt/pref*), but at least you can tell it to try harder. :-/
 
 I shouldn't, I really shouldn't, but well, I bite…
 
 This isn't trying harder, it is trying increasingly incorrect solutions
 to the problem because aptitude assumes the users is not able to express
 himself correctly. apt-get is treating its user as its god instead, aka:
 user is always right, even if it makes no sense in apt's simple mind.
 
My main problem is that, whenever I install a difficult package, the
first solution I get presented is always to simply not install the package
in question. The next 2^n-1 solutions transitively remove everything that
currently conflicts with installing the thing in question. Rejecting the
removal of a few core packages then gets me the correct solution, e.g.
upgrading two packages.

 Selecting one package in an or-group is a grand example of people not
 understand their tools although the policy is simple and logic: If it
 isn't impossible to let it win, the first alternative wins. If the
 package manager would go for any heuristic based on simplicity of
 installation instead everyone would have lsb-invalid-mta as MTA because
 that is damn easy to install by any standard. Maintainers are very
 heavily relying on this property while e.g. building packages.

You don't have to drop that part of its logic. Choosing a different package
as a dependency should of course be a last resort action (i.e. be heavily
penalized). I'm not talking about changing that. I'm talking about the fact
that aptitude treats upgrading to a slightly-lower-prioritized version of a
package as a *way* worse solution than removing that package (and/or 500
others).

Basically, this boils down to the fact that people shouldn't have to read a
manpage about a complex priority scheme in an equally-complex resolver.
All I want is for aptitude to behave in a sane way by default.

Its current behavior is not.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019073253.ga24...@smurf.noris.de



Re: apt-get install sysvinit-core removes gnome?

2014-10-19 Thread Thomas Krennwallner
On Sun Oct 19, 2014 09:32:54AM +0200, Matthias Urlichs wrote:
 David Kalnischkies:
  Selecting one package in an or-group is a grand example of people not
  understand their tools although the policy is simple and logic: If it
  isn't impossible to let it win, the first alternative wins. If the
  package manager would go for any heuristic based on simplicity of
  installation instead everyone would have lsb-invalid-mta as MTA because
  that is damn easy to install by any standard. Maintainers are very
  heavily relying on this property while e.g. building packages.
 
 You don't have to drop that part of its logic. Choosing a different package
 as a dependency should of course be a last resort action (i.e. be heavily
 penalized). I'm not talking about changing that. I'm talking about the fact
 that aptitude treats upgrading to a slightly-lower-prioritized version of a
 package as a *way* worse solution than removing that package (and/or 500
 others).
 
 Basically, this boils down to the fact that people shouldn't have to read a
 manpage about a complex priority scheme in an equally-complex resolver.
 All I want is for aptitude to behave in a sane way by default.

I think it's time to use apt-cudf. On a standard sid installation with
gnome, it could perfectly resolve this situation:

 % apt-get -s --solver aspcud install sysvinit-core 

 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Execute external solver... Done
 The following extra packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim
 The following packages will be REMOVED:
   systemd-sysv
 The following NEW packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim sysvinit-core
 0 upgraded, 6 newly installed, 1 to remove and 0 not upgraded.

Compare with apt-get without aspcud:

 % sudo apt-get -s install sysvinit-core
 
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 The following package was automatically installed and is no longer required:
   linux-image-amd64
 Use 'apt-get autoremove' to remove it.
 The following extra packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim
 The following packages will be REMOVED:
   aptdaemon brasero colord gdm3 gnome gnome-bluetooth gnome-color-manager 
gnome-control-center gnome-core gnome-disk-utility gnome-packagekit
   gnome-packagekit-session gnome-session gnome-settings-daemon gnome-shell 
gnome-shell-extensions gnome-sushi gnome-system-log gnome-user-share gvfs
   gvfs-backends gvfs-daemons gvfs-fuse libpam-systemd nautilus nautilus-sendto 
network-manager network-manager-gnome packagekit packagekit-tools
   policykit-1 policykit-1-gnome systemd-sysv task-gnome-desktop udisks2
 The following NEW packages will be installed:
   cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim sysvinit-core
 0 upgraded, 6 newly installed, 35 to remove and 0 not upgraded.

Best,
TK


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019090313.ga29...@kr.tuwien.ac.at



Re: apt-get install sysvinit-core removes gnome?

2014-10-19 Thread Holger Levsen
Hi,

cc:ing the apt maintainers to get their opinion on making this the default...

On Sonntag, 19. Oktober 2014, Thomas Krennwallner wrote:
  Basically, this boils down to the fact that people shouldn't have to read
  a manpage about a complex priority scheme in an equally-complex
  resolver. All I want is for aptitude to behave in a sane way by default.
 
 I think it's time to use apt-cudf. On a standard sid installation with
 gnome, it could perfectly resolve this situation:
 
  % apt-get -s --solver aspcud install sysvinit-core
[keeps gnome]
[...]
 Compare with apt-get without aspcud:
  % sudo apt-get -s install sysvinit-core
[removes gnome]

wow.

I guess the usual too late for jessie applies, though, or?


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.


Re: apt-get install sysvinit-core removes gnome?

2014-10-19 Thread Julian Andres Klode
On Sun, Oct 19, 2014 at 1:34 PM, Holger Levsen hol...@layer-acht.org wrote:
 Hi,

 cc:ing the apt maintainers to get their opinion on making this the default...

aspcud is not suitable as a default solver. It is far too slow and
ignores some aspects people are accustomed to, like a Depends: a | b
installing a whenever possible. Same for all other CUDF solvers.


 On Sonntag, 19. Oktober 2014, Thomas Krennwallner wrote:
  Basically, this boils down to the fact that people shouldn't have to read
  a manpage about a complex priority scheme in an equally-complex
  resolver. All I want is for aptitude to behave in a sane way by default.

 I think it's time to use apt-cudf. On a standard sid installation with
 gnome, it could perfectly resolve this situation:

  % apt-get -s --solver aspcud install sysvinit-core
 [keeps gnome]
 [...]
 Compare with apt-get without aspcud:
  % sudo apt-get -s install sysvinit-core
 [removes gnome]

 wow.

 I guess the usual too late for jessie applies, though, or?

Something strange is going on there. If I do the same on my system
which has its own GNOME meta packages currently, I get:

The following package was automatically installed and is no longer required:
  gnome-packagekit-data
Use 'apt-get autoremove' to remove it.
The following extra packages will be installed:
  acpi-fakekey acpi-support acpi-support-base acpid cgmanager ethtool
libcgmanager0 libck-connector0 libnih-dbus1 libnih1
libpam-ck-connector
  pm-utils systemd-shim
Suggested packages:
  radeontool consolekit
The following packages will be REMOVED:
  gnome-packagekit gnome-packagekit-session gnome-session-flashback systemd-sysv
The following NEW packages will be installed:
  acpi-fakekey acpi-support acpi-support-base acpid cgmanager ethtool
libcgmanager0 libck-connector0 libnih-dbus1 libnih1
libpam-ck-connector
  pm-utils systemd-shim sysvinit-core
0 upgraded, 14 newly installed, 4 to remove and 102 not upgraded.

Although none of gnome-packagekit gnome-packagekit-session
gnome-session-flashback need to be removed. I thus believe gnome gets
removed because it depends on gnome-packagekit which APT somehow
thinks it has to remove.
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAEA6rAx2mTXoPm89h2sDZh1MG6web8RB=8zuz5icyioqnaj...@mail.gmail.com



Re: apt-get install sysvinit-core removes gnome?

2014-10-18 Thread David Kalnischkies
On Thu, Oct 16, 2014 at 01:20:54PM +0200, Matthias Urlichs wrote:
 Florian Lohoff:
  is it intentional that gnome is removed when systemd is replaced by 
  sysvinit-core?
 
 Please always retry this kind of thing with aptitude, and try to let it
 choose alternate resolutions to the dependency chains.
 
 Apitude, too, *really* likes to choose 500 deletions rather than upgrading
 even a single package to a version with slightly-lower priority (as defined
 in /etc/apt/pref*), but at least you can tell it to try harder. :-/

I shouldn't, I really shouldn't, but well, I bite…

This isn't trying harder, it is trying increasingly incorrect solutions
to the problem because aptitude assumes the users is not able to express
himself correctly. apt-get is treating its user as its god instead, aka:
user is always right, even if it makes no sense in apt's simple mind.

Selecting one package in an or-group is a grand example of people not
understand their tools although the policy is simple and logic: If it
isn't impossible to let it win, the first alternative wins. If the
package manager would go for any heuristic based on simplicity of
installation instead everyone would have lsb-invalid-mta as MTA because
that is damn easy to install by any standard. Maintainers are very
heavily relying on this property while e.g. building packages.

Beside that with every alternative you choose a non-default package for
you move further into here be dragons land so that should really not
be the first suggestion if it can be avoided.

A user who on the other hand already knows what he wants has a multitude
of options to express his needs/requirements, it is just a matter of how
to do it properly…


I shouldn't be the one advising against using any aptitude option,
because I have no experience with it, but I have enough dependency
resolver experience to be able to say that optimising along less removes
is very dangerous: Apart from the lsb-invalid-mta example mentioned
above, such a setting has no problem with removing essential packages
(remember, close to nothing has a positive dependency on it) and
aptitude not even has a scary warning for it. I think you should know
that before its removing dpkg on your next dist-upgrade (okay, it will
not be dpkg, too many positive dependencies for that for now).  So act
like the chosen configfile name suggests and read the manual, aptitude
has one and it documents these kind of things for a reason…

If that isn't enough motivation to read it already, let me tell you that
the suggested setting isn't even helping in the scenario you described
as you optimize for priority first…


In terms of the I don't want package X problem class its easiest to
simply tell the package manager that this is the case. Negative pins and
action modifiers on the commandline come to mind.

The don't be an idiot problem is a bit harder. I actually like apt-get
for being so simple minded as it means I can easily follow its thought
process. The problem with removes is that we tend to bundle a big bunch
of different cases into the same group ranging from these two packages
can no longer co-exist; choose wisely as you will loose functionality
all the way down to this is a transitional package nobody will miss.
If you have a clever idea how to solve this, I am all ears…


Moo,

David Kalnischkies


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-17 Thread Matthias Urlichs
Hi,

Martin Read:
 I got sick of remove half the planet being the first suggested option, so
 added a configuration fragment to /etc/apt/apt.conf.d that gets a behaviour
 I find more reasonable:
 
Ah. Thank you very much. I'll add that to my generic all my Debian stuff
should have this package.

IIRC I already filed a bug on Aptitude about this, but given that the thing
currently has 700+ open bugs …

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141017075119.ga5...@smurf.noris.de



Re: Re: apt-get install sysvinit-core removes gnome?

2014-10-17 Thread Jonathan de Boyne Pollard

Dominik George:

There is no GNOME without systemd. This is not specific to Debian.


Florian Lohoff:

Because i - aehm - cant set an icon for my system via hostnamed or something?


As you've spotted, what M. George wrote is ambiguous and unspecific and liable 
to be further distorted.  This may help:

* 
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/debian-systemd-packaging-hoo-hah.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5441b377.2060...@ntlworld.com



apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Florian Lohoff

Hi,

is it intentional that gnome is removed when systemd is replaced by 
sysvinit-core?
an

apt-get install sysvinit-core sysvinit-utils

on a fresh jessie removed most of the gnome desktop.

I dont want systemd and i'd like to remove as much of the blob as possible. I 
thought
systemd-shim + sysvinit-core/utils would be enough to make a usable system
but it seems there is some dependency in jessie which makes gnome unavailable
without systemd.

Am i wrong?

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Dominik George
Hi,

but it seems there is some dependency in jessie which makes gnome
unavailable
without systemd.

It is there because upstream requires it. There is no GNOME without systemd. 
This is not specific to Debian.

-nik


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/09e6843b-eb29-4082-8868-d9617b053...@naturalnet.de



Re: apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Emilio Pozuelo Monfort
On 16/10/14 12:47, Dominik George wrote:
 Hi,
 
 but it seems there is some dependency in jessie which makes gnome
 unavailable
 without systemd.
 
 It is there because upstream requires it. There is no GNOME without systemd. 
 This is not specific to Debian.

No, that's wrong.

$ sudo aptitude install sysvinit-core
The following NEW packages will be installed:
  sysvinit-core 
0 packages upgraded, 1 newly installed, 0 to remove and 204 not upgraded.
Need to get 130 kB of archives. After unpacking 253 kB will be used.
The following packages have unmet dependencies:
 systemd-sysv : Conflicts: sysvinit-core but 2.88dsf-53.4 is to be installed.
Internal error: found 2 (choice - promotion) mappings for a single choice.
Internal error: found 2 (choice - promotion) mappings for a single choice.
The following actions will resolve these dependencies:

  Remove the following packages:
 
1)  aptdaemon   
 
2)  brasero 
 
3)  colord  
 
4)  gdm3
 
5)  gnome-control-center
 
6)  gnome-disk-utility  
 
7)  gnome-session   
 
8)  gnome-settings-daemon   
 
9)  gnome-shell 
 
10) gnome-shell-dbg 
 
11) gvfs
 
12) gvfs-backends   
 
13) gvfs-daemons
 
14) gvfs-dbg
 
15) gvfs-fuse   
 
16) hplip   
 
17) libpam-systemd  
 
18) nautilus
 
19) nautilus-sendto 
 
20) network-manager 
 
21) network-manager-gnome   
 
22) packagekit  
 
23) packagekit-tools
 
24) policykit-1 
 
25) policykit-1-gnome   
 
26) printer-driver-postscript-hp
 
27) steadyflow  
 
28) systemd-sysv
 
29) udisks2 
 

  Leave the following dependencies unresolved:  
 
30) python-aptdaemon recommends aptdaemon   
 
31) python3-aptdaemon recommends aptdaemon  
 
32) libcolord2 recommends colord
 
33) libcolord-gtk1 recommends colord
 
34) cups recommends colord  
 
35) cups-daemon recommends colord   
 
36) cups-filters recommends colord  
 
37) empathy recommends gvfs-backends
 
38) evince recommends gvfs  
 
39) file-roller recommends gvfs 
 
40) gnome-calculator recommends gvfs
 
41) gnome-control-center-data recommends gnome-control-center (= 
1:3.14.0-1)
42) gnome-media recommends gnome-control-center 
 
43) gnome-online-accounts recommends gnome-control-center (= 3.6.1)
 
44) gnome-session-bin recommends libpam-systemd 
 
45) gnome-shell recommends gnome-control-center 
 
46) gnome-system-monitor recommends gvfs
 
47) gnome-terminal recommends gvfs  
 
48) gvfs-common recommends gvfs  

Re: apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Florian Lohoff
On Thu, Oct 16, 2014 at 12:47:41PM +0200, Dominik George wrote:
 Hi,
 
 but it seems there is some dependency in jessie which makes gnome
 unavailable
 without systemd.
 
 It is there because upstream requires it. There is no GNOME without systemd. 
 This is not specific to Debian.

*örgs* Because i - aehm - cant set an icon for my system via hostnamed or
something?

I still wait to wake up to let this bad dream of systemd go past me. This
can only be a bad dream ...

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Matthias Urlichs
Hi,

Florian Lohoff:
 is it intentional that gnome is removed when systemd is replaced by 
 sysvinit-core?

Please always retry this kind of thing with aptitude, and try to let it
choose alternate resolutions to the dependency chains.

Apitude, too, *really* likes to choose 500 deletions rather than upgrading
even a single package to a version with slightly-lower priority (as defined
in /etc/apt/pref*), but at least you can tell it to try harder. :-/

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016112053.ga17...@smurf.noris.de



Re: apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Martin Read

On 16/10/14 12:20, Matthias Urlichs wrote:

Apitude, too, *really* likes to choose 500 deletions rather than upgrading
even a single package to a version with slightly-lower priority (as defined
in /etc/apt/pref*), but at least you can tell it to try harder. :-/


I got sick of remove half the planet being the first suggested option, 
so added a configuration fragment to /etc/apt/apt.conf.d that gets a 
behaviour I find more reasonable:


mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
Aptitude::ProblemResolver {
SolutionCost priority, removals, canceled-actions;
}
mormegil@cocytus:~$

(Yes, the choice of filename does reflect a certain amount of... 
*grouchiness* on my part regarding the default behaviour of the aptitude 
interactive dependency resolver. This is a home system; if I was writing 
this up as a general-purpose article I'd give it a less loaded name.)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ff3bd.1020...@zen.co.uk



Re: apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Bas Wijnen
On Thu, Oct 16, 2014 at 05:35:09PM +0100, Martin Read wrote:
 mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
 Aptitude::ProblemResolver {
 SolutionCost priority, removals, canceled-actions;
 }

That looks very useful, thanks!
Bas


signature.asc
Description: Digital signature


Re: apt-get install sysvinit-core removes gnome?

2014-10-16 Thread Svante Signell
On Thu, 2014-10-16 at 20:36 +0200, Bas Wijnen wrote:
 On Thu, Oct 16, 2014 at 05:35:09PM +0100, Martin Read wrote:
  mormegil@cocytus:~$ cat /etc/apt/apt.conf.d/00dontbeanidiot
  Aptitude::ProblemResolver {
  SolutionCost priority, removals, canceled-actions;
  }
 
 That looks very useful, thanks!

How to configure apt pinning? Just for the record (to be published
where?) (or does this apply to apt too, not only aptitude?)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413485223.27347.17.ca...@g3620.my.own.domain