The Latest Fedora Debate: DNF Can Remove Systemd, RPM

[Grogan]

Yes, with power comes the ability to shoot yourself in the foot. To me this sounds like good news, I'm sick and tired of the dumbing down and crippling of Linux distributions.

When a stupid package manager doesn't do what I want, I resort to package management utilities like "rm" and then I tend to not use the distro's packages ever again because now there are discrepancies in the package database.

I like Slackware's packaging... unconditionally remove/install/upgrade/downgrade anything you want. It's not that difficult to determine what you're going to break by removing a package. Real dependencies are much easier to satisfy than arbitrarily specific ones dictated by some package management system. Your package database is text files that list every object and you can view the filenames and grep them to your heart's content while booted with anything that can access the filesystem. It's a Hell of a lot better than having to use things like "rpm -q" or "dpkg-query" to find those things out.

It's fucking stupid. For example, I wanted a better ffmpeg installation (including shared libraries that I can link against) than what Linux Mint provides. ffmpeg is one of those things where if I want it done right, I have to do it myself. The package itself isn't a dependency for anything, but some of the libraries it provides are used by components of the system. So the only way to deal with this is to break it. If you try to remove libavcodec or any of the other separately packaged ffmpeg shared libraries it prompts to remove a lot of stuff. Can't do that, so it's "rm".

Knowing that my libraries will work to satisfy the real dependencies, it's maddening to have to deal with a lame dependency system that will cause problems if you circumvent it. That's why it's game over for distro packages once I start doing this. I don't need any more circular logic imposed on me.

The only reason I suffer this horseshit is because I need a Steam friendly multi-lib distro, but I'm starting to feel like it's not worth the bother.

[Pisto]

use yum-builddep and the fact that 90% of software installs to /usr/local.

[Grogan]

use yum-builddep and the fact that 90% of software installs to /usr/local.

Installing software to /usr/local when a distro package exists will cause problems too. I don't just care about runtime dependencies, I actually want to be able to compile and link without having to work around failures. Even if, say for example, you have the correct includes in /usr/local (and no "dev" package so there's none for it in /usr/include) and your build uses the correct libraries in /usr/local/lib at compile time, when it comes time for the final linking step it can fail if it's getting the library in /usr/lib. I know, it's not supposed to happen but it does.

[AdamW]

i myself just dont think DNF is ready to replace YUM as default. not till F23 atleast. , if its still goes on as default in F22 i'll switch over to opensuse

Can I borrow your crystal ball? I'd love to be able to know whether software will be ready by the time not even the *next* Fedora release comes out, but *the one after that*. Which doesn't have even a draft release schedule yet.

[AdamW]

They should be hardcoded, but they should not be hardcoded *in the package manager*.
This kind of stuff should go inside the distribution it-self.
For example, suse does it with a bunch of special "Pattern" package that describe general use (it's similar concept to gentoo's virtual package). These "patterns" pull-in a bunch of necessary package without which a system would not be usable for a given usage pattern. When the distribution upgrades, these "patterns" get upgraded too and might pull in a different set of requirement.
(In the example of the current "DNF vs. Kernel and glibc", there should be a "basic bootable system" patterns that requires on package that provides "kernel" and that require one the various packages (Glibc, ucLibc, etc.) that provide "c library". The badly broken "prce" package would have resulted into the solver complaining that it conflict dependencies of "basic bootable system")

There was no "badly broken pcre package". The person complaining didn't run "dnf update" and find that some error in the pcre package caused dnf to propose removal of kernel, rpm etc. The person complaining ran "dnf remove pcre". No metapackage tricks will "protect" against that.

[Luke]

In Debian you can use "provides" to satisfy package manager dependencies

For example, I wanted a better ffmpeg installation (including shared libraries that I can link against) than what Linux Mint provides. ffmpeg is one of those things where if I want it done right, I have to do it myself. The package itself isn't a dependency for anything, but some of the libraries it provides are used by components of the system. So the only way to deal with this is to break it. If you try to remove libavcodec or any of the other separately packaged ffmpeg shared libraries it prompts to remove a lot of stuff. Can't do that, so it's "rm".

Knowing that my libraries will work to satisfy the real dependencies, it's maddening to have to deal with a lame dependency system that will cause problems if you circumvent it. That's why it's game over for distro packages once I start doing this. I don't need any more circular logic imposed on me.

In Debian you can fix this two ways: The simplest way is to leave the package "installed" but remove all the files, then pin it until this blocks an update, then unpin and repeat. The correct way is to create an empty dummy package that "provides" the offending package in DEBIAN/control . That's what I did about cinnamon-control-center depending on Pulseaudio. The volume controls in Cinnamon are compiled against Pulseaudio and do not work if it's removed, strangely only the control center and not cinnamon itself actually depend on it. I made a "pulseaudio-dummy" package that tells dpkg that pulseaudio is installed, then installed Volti to get a working volume control. This was to maximize video performance in kdenlive playback.,

[AdamW]

It's fucking stupid. For example, I wanted a better ffmpeg installation (including shared libraries that I can link against) than what Linux Mint provides. ffmpeg is one of those things where if I want it done right, I have to do it myself. The package itself isn't a dependency for anything, but some of the libraries it provides are used by components of the system. So the only way to deal with this is to break it. If you try to remove libavcodec or any of the other separately packaged ffmpeg shared libraries it prompts to remove a lot of stuff. Can't do that, so it's "rm".

Knowing that my libraries will work to satisfy the real dependencies, it's maddening to have to deal with a lame dependency system that will cause problems if you circumvent it. That's why it's game over for distro packages once I start doing this. I don't need any more circular logic imposed on me.

Er, that's not fucking stupid, you're doing something fairly stupid. You either work within your distribution packaging system or outside it. If you want to use self-compiled libraries, you'd better self-compile the dependent apps - or alternatively, you can build your own super-duper libavcodec as a package, and ensure it really *does* provide the same things the official distro package does.

But no, you can't expect your distro's packaging system to magically work with libraries you have self-compiled entirely outside of the packaging system.

[Nobu]

It's fucking stupid. For example, I wanted a better ffmpeg installation (including shared libraries that I can link against) than what Linux Mint provides. ffmpeg is one of those things where if I want it done right, I have to do it myself. The package itself isn't a dependency for anything, but some of the libraries it provides are used by components of the system. So the only way to deal with this is to break it. If you try to remove libavcodec or any of the other separately packaged ffmpeg shared libraries it prompts to remove a lot of stuff. Can't do that, so it's "rm".

This is why I like ArchLinux, it's simple:

wget $AUR/package.tar.gz
tar xvf package.tar.gz && cd package/
#make whatever changes you want,
#verify it's not going to eat your computer:
nano -w PKGBUILD
makepkg -cris #install builddeps, build, install, cleanup

pacman handles all the deps automatically. If the PKGBUILD provides the correct package, it like a simple upgrade. If not, it's easy enough to modify the PKGBUILD.

[AdamW]

This is why I like ArchLinux, it's simple:

wget $AUR/package.tar.gz
tar xvf package.tar.gz && cd package/
#make whatever changes you want,
#verify it's not going to eat your computer:
nano -w PKGBUILD
makepkg -cris #install builddeps, build, install, cleanup

pacman handles all the deps automatically. If the PKGBUILD provides the correct package, it like a simple upgrade. If not, it's easy enough to modify the PKGBUILD.

eh. it's really not that different on a 'traditional' distribution.

fedpkg clone (package)
cd package
nano package.spec
(change build config, add .1 to "Release:", add a changelog if you want to be neat and remember what you did later)
fedpkg srpm
fedpkg local (to do a local build), fedpkg mock (to do a local 'scratch' build)
install built package

I'm sure there are similar workflows for SUSE, Debian etc etc. People who run binary distros don't tend to do stuff like this, but it's not like you can't.

[gens]

I'm sure there are similar workflows for SUSE, Debian etc etc. People who run binary distros don't tend to do stuff like this, but it's not like you can't.

semi unrelated
in slackware

[I]blabla[/I]

make DESTDIR=$A_TMP_PACKAGE_FOLDER install

cd [I]there[/I]

/sbin/makepkg [I]some options and output filename[/I]

where makepkg is a simple script using tar and some logic
so making any kind of package is straightforward (also well documented, as other are)
(salix and a couple more add dependency resolving via a text file that is plonked in)


to add;
no mater what Grogan's case was, upgrading ffmpeg will not break stuff since they keep a stable API on point releases (unlike some)
doing stuff yourself, if you want to, is a great way to learn