+- nixers (https://nixers.net)
+-- Forum: Desktop Customization, Efficiency, and Aesthetics (https://nixers.net/Forum-Desktop-Customization-Efficiency-and-Aesthetics)
+--- Forum: Desktop Customization & Workflow (https://nixers.net/Forum-Desktop-Customization-Workflow)
+--- Thread: pkg management, what do you expect, what you wished you had (/Thread-pkg-management-what-do-you-expect-what-you-wished-you-had)
pkg management, what do you expect, what you wished you had - venam - 23-05-2016
(This is part of the podcast discussion extension)
pkg management, what do you expect, what you wished you had.
It was an interesting talk. Everyone had their own ideas about package management.
What spiced up the topic was that it's something that we all use on a daily basis and depend upon.
Moreover, some even wrote their own package managers.
We scratched many attributes of the package management.
An easy to understand package format
By package format we mean the type of file the package is made of.
For example it can be a compressed file or a simple text file.
.deb file format which is tarball, needs to be extracted to check what's inside.
The .deb files contain patches and other things needed for the installation.
An easy way to write your own packages
We made a lot of comparisons.
The slpm package manager was mentioned https://github.com/radare/slpm as one of the most easy to write your own packages with.
For instance, the CURL pkg has only 3 lines of code: https://raw.githubusercontent.com/radare/slpm/master/pkg/curl-7.21.4
It was then put against others such as yum (rpm), which everyone seemed to hate but corporations love,
pacman (pkgbuild), which everyone seemed to agree that it was verbose and relatively easy to write your own pkg with, and deb (apt), which is extended but "not that terrible once you get used to it" (kirby).
We then argued about the meaning of the "simplicity" of writing your own packages and agreed that it's about having an easy way to mention the dependencies and the location of the installed files.
Keeping track of the installed files
When a package is installed it spreads out around the filesystem and leaves multiple files in a dozens of places.
The package manager should be smart enough to remove them (when the package is uninstalled) move them around or back them up (when a package is updated).
An easy way to search for dependencies
It is annoying when you install a package and don't know from which other package its dependencies are from, especially when compiling.
Thus, there should be a way to search where that file is in what other pkgs have it.
apt lets you install a package even though its dependencies aren't met but once you try to install something else it asks you to run:
Code:
apt-get install -f #install what is needed for a pkgThe speed of installation doesn't matter but the speed of the mirrors do
The mirrors of the Arch repos goes up in down sometimes but they solve it by giving to the users scripts which will give you the fastest mirror.
Meaningful commands and flags
We scratched the subject a bit saying that it's not fun to have to remember the meaning of flags when the letter used is not related to the action that is going to be made.
Pacman was mentioned as one of the worse.
Easily see what's going to be updated
When updating the whole system some users want to avoid updating certain packages and the package manager should offer a way to foresee what is going to be updated so that those packages can be added to the ignore list.
Apt is quite hard to use while, pacman has the -Qu flags for specially made for that purpose, and CRUX dependency tree which prettily displays the needed information.
Easily rollback
All package managers should have a cache of old packages so that users can downgrade them.
The number of available packages and the age of the packages
We argued about the meaning of stable, unstable, rolling, and testing
We mentioned CRUX as one of the most stable rolling distro.
Overall, we all want the most recent packages if they are usable (vim ftw).
Should we have a local/user pkg manager VS an operating system/global pkg manager
An operating system pkg manager would be the one that installs /usr/bin for the whole system while a local package manager is one that installs packages for a single user without the need for root access.
(
-side talk-
/usr/bin or /bin or the same if you are running Arch because they have been merged.
Is one directory for /bin easier for file tracking or will it hinder by increasing the chance for conflicts?
NB: GNU/coreutil installs the same files multiple time
)
The purpose of the local package manager is to have less requirements, more secure, and more user defined.
For example, at university, they might give all users a custom pkg managers to install what they need in their home directory.
With apt installing in the home can be done in the following way:
Code:
apt-get download package; dpkg -i —force-not-root —root=$HOME package.debIs there a need to make such difference? (global/local)
It might complicate the update process because local pkgs might depend on the operating system and libraries.
For that there should be a way for the global package manager to know the roots of all other local pkg managers to keep track of the profiles.
Or, maybe, something like Puppet to control all the local pkgs on all users and update them on orders.
Why corporation love YUM and RPMs
Corporations live off Centos, Redhat, Opensuse, and Fedora mainly because of the long term support and contracts.
It was repeatedly said during the podcast that writing rpms is a "pain in the ass"(z3bra).
That yum was extremely slow because it refetches the cache at startups.
We'll see how it goes with DNF, the forked version of YUM that is now replacing it.
More info here: http://dnf.baseurl.org/2015/05/11/yum-is-dead-long-live-dnf/
Windows 10 pkg management
Windows is late in the game. Unix had package management since the beginning.
No one tried it but we laughed a lot when we saw that it was for the powershell.
Writing a pkg manager is hard
Some members wrote their own package management tools and told us about the development process.
The process of downloading, fetching dependencies, and installing was said to be fairly easy.
The hardest part of the development is to clean what was installed with the package. (keeping track of files)
On updates it is a dilemma to choose what to do with the old config files.
Should you overwrite them, rename them to .old, or the save the new one with a .new extension.
Links to custom package managers by our members:
http://git.z3bra.org/cgit.cgi/pmkit/
https://github.com/agnopm/agno
Thank you all for joining the podcast this week!
°˖✧◝(⁰▿⁰)◜✧˖°
RE: pkg management, what do you expect, what you wished you had - z3bra - 27-05-2016
I want package management to be simple. Currently, I'm not fully happy with what's in the wild.
Here are the features, I think, are mandatory:
- Simple build recipes
- Reproductible builds
- Simple packaging format (eg; tarballs)
- Ability to sign/check a package
RE: pkg management, what do you expect, what you wished you had - jkl - 27-05-2016
The one thing I've been missing since my last Linux desktop machine was changed from Fedora to BSD is "yum rollback". It should be possible to roll back any past package action without affecting others.
AFAIK Nix does that, but it does not seem to be supported on BSD according to the website.
RE: pkg management, what do you expect, what you wished you had - z3bra - 27-05-2016
This is actually a good feature. But on dynamically linked systems, it's not always possible to simply rollback a package without affecting another.
For example, if you rollback firefox, that was compiled against a previous version of libjpeg, you also need to rollback libjpeg to have firefox working. But many other packages rely on it! so you'll end up rollbacking way more packages than expected.
This issue is indeed solved by statically compiled softwares, which is what I tend to prefer. There are drawbacks in static compilation too, but I think they outcome those of dynamic compilation.
That's another debate anyway.
I never had to use "yum rollback" before, so I don't know how dependencies are handled.