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

  • #31
    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...

    Comment


    • #32
      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.

      Comment


      • #33
        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.

        Comment


        • #34
          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.

          Comment


          • #35
            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.

            Comment


            • #36
              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

              Comment


              • #37
                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...

                Comment


                • #38
                  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

                  Comment


                  • #39
                    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

                    Comment


                    • #40
                      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.

                      Comment

                      Working...
                      X