Don't Use Fedora's Fedup Right Now Due To A Bug With Systemd

[MoonMoon]

N

and here is an honest answer
i had debian jessie with xfce on a laptop and i removed networkmanager and its gtk applet
couple days later i wanted to put it back
installing nm-applet pulled in networkmanager, but it also pulled in gnome3 and systemd
i'm sure there is some logic behind it doing that, but what happened is just stupid

That is a problem with Debian's package management, not systemd's dependencies, and since you are using Testing I am sure that you filed a bug report already and soon will get an answer.

[gens]

the bullshit 'for no good reason' was insulting, but somehow you didn't care
telling brainless people thruth is not insulting

what he said was the truth

[pal666]

and for the nth time you insult people...

the bullshit 'for no good reason' was insulting, but somehow you didn't care
telling brainless people thruth is not insulting

[gens]

For the n-th time: there are good reasons, but some people have too small brains to understand it. and when some other software depends on systemd it is not a systemd's fault. it is a fault either of that software or of shitty systemd alternatives

and for the nth time you insult people...

[pal666]

For the n-th time: the problem is not systemd as an alternative, quite the contrary. The problem is that systemd is forcing people to use systemd through dependencies, leaving any alternatives on their own, for no good reason (other than "my feels" and "my innovation").

For the n-th time: there are good reasons, but some people have too small brains to understand it. and when some other software depends on systemd it is not a systemd's fault. it is a fault either of that software or of shitty systemd alternatives

[valeriodean]

For the n-th time: the problem is not systemd as an alternative, quite the contrary. The problem is that systemd is forcing people to use systemd through dependencies, leaving any alternatives on their own, for no good reason (other than "my feels" and "my innovation").


Of course alpha software is dangerous, but how would you solve a problem that is considered a "feature"? Also, you should tell Arch users that their whole distro is dangerous

Well, I like the cutting-edge approach and I like to have the latest and the greatest, however one thing is to have the last release of the software, another thing is to run the alpha release.
The purpose of the alpha release is to find the problems before the final release is out. Blame the developers because there is a bug in the alpha software is ridiculous: they exists exactly for that purpose.

The real problem is how you should test the software?
Who want to help in testing should not mix the production release with alpha release. It depends on what you want to test, but in general you should have a dedicated partition for that purpose, or to use an ISO, or install the alpha software in another place (as per LibreOffice, the alpha release are co-installable with the production release), but you should *not* put yourself in the condition to break your production system because of the test.

[dungeon]

and here is an honest answer
i had debian jessie with xfce on a laptop and i removed networkmanager and its gtk applet
couple days later i wanted to put it back
installing nm-applet pulled in networkmanager, but it also pulled in gnome3 and systemd
i'm sure there is some logic behind it doing that, but what happened is just stupid

I guess we can thanks Mr. Lennart for that

http://anonscm.debian.org/cgit/pkg-utopia/network-manager.git/commit/?id=69b95405b07fc2a5833dfcbe18c9229706c2104e

We merged libsystemd-journal.so, libsystemd-id128.so, libsystemd-login
and libsystemd-daemon into a a single libsystemd.so to reduce code
duplication and avoid cyclic dependencies (see below). The new library
exports the same symbols as the old libraries, however with a different
symbol version. If "--enable-compat-libs" is specified while building
systemd you will get a set of compatibility libraries built that simply
map the old library calls to the new library. This is provided only to
ease the transition, please don't forget to pass "--disable-compat-libs"
(which is the default) after your distribution completed the
transition. Sorry for the complexities this involves!

Only thing i don't know, how he *always* know what distribution I am

[dungeon]

This is because the dependencies in Debian are retarded. The policy is "enable all features by default", which causes massive pulls every time you want to install something.
Today I wanted to install gnome-calculator from LXDE, the little bastard wanted to pull no less than 300megabytes of deps...

You can disable recommends/suggests/etc if you want that kind of lightweight approach . In /etc/apt/apt.conf or /etc/apt/apt.conf.d/70debconf put:

APT::Install-Recommends "0";
APT::Install-Suggests "0";

If you use synaptic, uncheck "Consider recommends packages as dependencies", etc.

[nanonyme]

From what I gather from the linked blog and bugzilla discussions, it *can* be disabled through a config file option. It's hard to get a clear picture, but it sounds like this is essentially a distribution bug - an interaction between a new systemd feature and a long-running on-boot process, which could easily have been addressed with that config option, if anyone had anticipated the problem before it caused problems.

Unfortunately, it's the usual "20/20 hindsight" thing, so they're having to clean up a problem that snuck through...

Well, it still can and F21 is not out yet. I'm personally expecting we don't want it disabled completely, just something that temporarily disables it on an upgrade. A boot parameter would assumably work since fedup has its own boot entry.

[Delgarde]

The showstopper, anyway, is that this behavior can't be disabled, or the booting period extended, by editing a config file.

From what I gather from the linked blog and bugzilla discussions, it *can* be disabled through a config file option. It's hard to get a clear picture, but it sounds like this is essentially a distribution bug - an interaction between a new systemd feature and a long-running on-boot process, which could easily have been addressed with that config option, if anyone had anticipated the problem before it caused problems.

Unfortunately, it's the usual "20/20 hindsight" thing, so they're having to clean up a problem that snuck through...