Announcement

Collapse
No announcement yet.

Red Hat Pushing DNF 5 Into Development For Improving The Package Manager

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by bug77 View Post

    I would also take this occasion to remind everyone the UNIX/Linux philosophy: use one tool for one job. Rolling many things into dnf seems to go against that.

    And about Python: speed of development. No compiled language (save maybe for Go) can match that.

    The "Unix philosophy" hasn't even been followed in Unix for a very long time. Software advances towards complexity. Multi uses for tools is preferable - by users - over single use tools that may or may not be remembered when you need one of them. I'm not saying complexity for the sake of complexity is good. I'm saying convenience and need will always trump some philosophy of a 40 year old obsolete paradigm.

    The "Unix philosophy" also included writing nearly everything you needed from scratch "back in the day". I know. I was there. I had to write quite a bit of stuff that wasn't available in the base systems back then. Or on some systems, had to write all your programs yourself to get anything done. This is why you ended up with chained single use tools that fed each other their output and god help you if one of the middle programs barfed for some reason and filled up a shared storage device.

    I agree with you about Python, however. It's a useful tool, and there are several ways of speeding up its execution versus the standard Python distribution.

    Comment


    • #62
      Originally posted by stormcrow View Post
      The "Unix philosophy" hasn't even been followed in Unix for a very long time.
      That's tangential, it's just a name for programming practices written down by people at the times Unix was a new thing and they saw themselves as "Unix founders" or something.

      The "Unix philosophy" also included writing nearly everything you needed from scratch "back in the day".
      No, that's how Unix systems worked in actual practice (and one of the reasons for their eventual demise)
      Same as above, "Unix phylosophy" is a name for a list of programming principles, it's not necessarily connected to actual Unixes.

      Some of these principles are indeed dated, most are not.

      Comment


      • #63
        Originally posted by Volta View Post
        The worst thing about it is the bash completion. It's a total nightmare. Not only it's utterly slow, but makes some irritating terminal sounds. However, there's some very good thing as well. It doesn't leave unneeded dependencies. When I install something with 40 dependencies I can be sure dnf will remove all of them. Sadly it's a feature that apt-get lacks.
        Which dependencies were you incapable of getting apt to remove?

        Comment


        • #64
          Originally posted by stormcrow View Post
          The "Unix philosophy" also included writing nearly everything you needed from scratch "back in the day". I know. I was there. I had to write quite a bit of stuff that wasn't available in the base systems back then. Or on some systems, had to write all your programs yourself to get anything done. This is why you ended up with chained single use tools that fed each other their output and god help you if one of the middle programs barfed for some reason and filled up a shared storage device.
          Thank Richard Stallman for GNU and the GPL and his vision to push for systems that were portable to all types of hardware.

          Comment


          • #65
            Originally posted by andyprough View Post

            Which dependencies were you incapable of getting apt to remove?
            I am capable, but I have remove them manually. Apt-get usually leaves some trash. Digikam as example:

            digikam digikam-data digikam-private-libs enblend enfuse gdal-data hugin hugin-data hugin-tools imagemagick imagemagick-6-common imagemagick-6.q16 kipi-plugins kipi-plugins-common libaec0 libarchive-zip-perl libarmadillo9 libarpack2 libastro1 libblas3 libcharls2 libdap25 libdapclient6v5 libepsilon1 libfreexl1 libfyba0 libgdal20 libgdcm2.8 libgeos-3.7.2 libgeos-c1v5 libgeotiff2 libgfortran5 libglew2.1 libgps23 libgsl23 libgslcblas0 libhdf4-0-alt libhdf5-103 libimage-exiftool-perl libkf5mediawiki5 libkmlbase1 libkmldom1 libkmlengine1 liblapack3 liblensfun-data-v1 liblensfun1 liblqr-1-0 libmagickcore-6.q16-6 libmagickcore-6.q16-6-extra libmagickwand-6.q16-6 libmarblewidget-qt5-28 libmime-charset-perl libnetcdf13 libnetpbm10 libodbc1 libogdi4.1 libopencv-core3.2 libopencv-highgui3.2 libopencv-imgcodecs3.2 libopencv-imgproc3.2 libopencv-ml3.2 libopencv-objdetect3.2 libopencv-videoio3.2 libpano13-3 libpano13-bin libposix-strptime-perl libpq5 libproj13 libpython-stdlib libpython2-stdlib libpython2.7 libpython2.7-minimal libpython2.7-stdlib libqhull7 libqt5serialport5 libqtav1 libqtavwidgets1 libshp2 libsocket++1 libsombok3 libspatialite7 libsuperlu5 libsz2 libtbb2 libunicode-linebreak-perl liburiparser1 libvigraimpex6 libwmf0.2-7 libwxbase3.0-0v5 libwxgtk3.0-gtk3-0v5 marble-plugins marble-qt-data minidlna netpbm odbcinst odbcinst1debian2 opencv-data proj-bin proj-data python python-minimal python2 python2-minimal python2.7 python2.7-minimal
            after removing (and autoremoving) packages it leaves following:

            imagemagick* imagemagick-6-common* imagemagick-6.q16* liblqr-1-0* libmagickcore-6.q16-6* libmagickcore-6.q16-6-extra* libmagickwand-6.q16-6* libnetpbm10* libpython2.7-minimal* libwmf0.2-7* minidlna* netpbm* odbcinst* python* python2.7-minimal*

            Comment


            • #66
              Originally posted by starshipeleven View Post
              Code:
               sudo zypper remove glibc
              [sudo] password for root:
              Reading installed packages...
              Resolving package dependencies...
              
              Problem: This request will break your system!
              conflicting requests
              
              Solution 1: ignore the warning of a broken system (requires:glibc)
              Solution 2: keep glibc-2.31-2.1.x86_64
              
              Choose from above solutions by number or cancel [1/2/c/d/?] (c):
              I mean, I get a warning, but I'm still technically allowed to ignore it and pull through, nuking the system. I've used this ability to ignore packaging requirements a few times to deal with broken (third party) packages in the past.

              And this is better than what apt does, it will not give warnings or anything, just dump a huge list of stuff to "delete" and ask to confirm. And does not allow you to install ignoring package requirements either, you must do stuff manually.
              So? What happened when you chose #1? We need pics of your smoking, smoldering Tumbleweed rig, or it didn't happen.

              Comment


              • #67
                Originally posted by Volta View Post

                I am capable, but I have remove them manually. Apt-get usually leaves some trash. Digikam as example:

                after removing (and autoremoving) packages it leaves following:
                You didn't purge? I thought you said you were capable.

                Comment


                • #68
                  Originally posted by andyprough View Post

                  You didn't purge? I thought you said you were capable.
                  Sure I did, apt-get purge and it left 90% of dependencies, so I have to use autoremove and then it left: imagemagick* imagemagick-6-common* imagemagick-6.q16* liblqr-1-0* libmagickcore-6.q16-6* libmagickcore-6.q16-6-extra* libmagickwand-6.q16-6* libnetpbm10* libpython2.7-minimal* libwmf0.2-7* minidlna* netpbm* odbcinst* python* python2.7-minimal*

                  Comment


                  • #69
                    Originally posted by Volta View Post

                    Sure I did, apt-get purge and it left 90% of dependencies, so I have to use autoremove and then it left: imagemagick* imagemagick-6-common* imagemagick-6.q16* liblqr-1-0* libmagickcore-6.q16-6* libmagickcore-6.q16-6-extra* libmagickwand-6.q16-6* libnetpbm10* libpython2.7-minimal* libwmf0.2-7* minidlna* netpbm* odbcinst* python* python2.7-minimal*
                    It's been awhile for me, but I believe the correct command is actually 'sudo apt-get purge --auto-remove <app>' if I recall correctly. Do it all at once. There's also 'dpkg --purge --force-depends <app>', but that's getting into some dangerous territory if you care about your system. Also, 'aptitude purge <app>' will do a good job if you originally installed with aptitude, as aptitude keeps a memory. One good reason to use aptitude for installing stuff you know you'll probably want to remove at some point.

                    Comment


                    • #70
                      Originally posted by andyprough View Post

                      So? What happened when you chose #1? We need pics of your smoking, smoldering Tumbleweed rig, or it didn't happen.
                      The VM crashed shortly after and couldn't boot anymore.
                      I mean it booted to the kernel, but the OS crashed and kernel panicked, reboot, and so on.
                      Yes I have a OpenSUSE VM on a OpenSUSE host for testing and development, no I don't care about its wellbeing as I have snapshots I can restore it with a couple clicks.
                      starshipeleven
                      Premium Supporter
                      Last edited by starshipeleven; 05 March 2020, 07:24 PM.

                      Comment

                      Working...
                      X