Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    MoonMoon
    Senior Member

  • MoonMoon
    replied
    N
    Originally posted by gens View Post
    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.

    Leave a comment:

  • gens
    Senior Member

  • gens
    replied
    Originally posted by pal666 View Post
    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

    Leave a comment:

  • pal666
    Senior Member

  • pal666
    replied
    Originally posted by gens View Post
    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

    Leave a comment:

  • gens
    Senior Member

  • gens
    replied
    Originally posted by pal666 View Post
    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...

    Leave a comment:

  • pal666
    Senior Member

  • pal666
    replied
    Originally posted by asdfblah View Post
    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

    Leave a comment:

  • valeriodean
    Senior Member

  • valeriodean
    replied
    Originally posted by asdfblah View Post
    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.

    Leave a comment:


  • dungeon
    replied
    Originally posted by gens View Post
    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-u...c9229706c2104e

    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
    Last edited by dungeon; 02 November 2014, 06:40 AM.

    Leave a comment:


  • dungeon
    replied
    Originally posted by doom_Oo7 View Post
    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:

    Code:
    APT::Install-Recommends "0";
    APT::Install-Suggests "0";
    If you use synaptic, uncheck "Consider recommends packages as dependencies", etc.
    Last edited by dungeon; 02 November 2014, 05:27 AM.

    Leave a comment:

  • nanonyme
    Senior Member

  • nanonyme
    replied
    Originally posted by Delgarde View Post
    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.

    Leave a comment:

  • Delgarde
    Senior Member

  • Delgarde
    replied
    Originally posted by mpppp View Post
    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...

    Leave a comment:

Working...
X