[SOLVED] what is {this package} and why do I want/need it?

SaintDanBert · 12-01-2015, 03:17 PM

I have a {package name} and want to discover what it is and why I might want or need it.
What is the best and simplest way to get that information?

often, package "descriptions" are little more than an expansion of the package name acronym or similar
many packages are bundles of other packages without a description of their own
if you don't know that {feature-name} is and why you might want one, the description "implements {feature-name}" (or language or protocol or ...) offers little information.

This situation presents most often after running some sort of update manager. The utility presents a list of packages that have available updates ... for example systemd. If one had no idea what that was or what was the value/purpose it is difficult to make good decisions about the effectiveness of the pending update.

As an aside, the formal package descriptions are most often marginally useful, but sometimes inform better searching for truly useful information.

Thanks in advance,
~~~ 0;-Dan

PS/ I chose systemd as my example because a simple Google search results in a monsoon of articles cussing and discussing -- much heat and little light -- about the package itself. The naive reader is forced to wade through a lot of chaff and manure in search of useful information. As a naive user, they are ill equipped to make informed decisions about the quality of that information.

sgosnell · 12-01-2015, 04:20 PM

You could run 'man packagename' in a terminal and get lots of information about it.

berndbausch · 12-01-2015, 05:01 PM

I would google it (debian systemd package description ==> first hit) or look at the documentation provided by the distro, such as wikis or help.ubuntu.com etc. If you think there isn't enough information, submit an enhancement request to the distro or use the distro's forum.

chrism01 · 12-01-2015, 05:37 PM

You've chosen a hard example there

Basically systemd is a replacement for the old SysV init+startup scripts.
Its a large binary, whereas the old scripts are shell text - this worries many people....

There is indeed some hard discussions as to whether its a good idea. However, it looks like most distros are going with it (atm) eg the latest RHEL (v7) uses it, so derivatives will as well.
See this https://wiki.freedesktop.org/www/Software/systemd/

HTH

berndbausch · 12-01-2015, 06:03 PM

Quote:

Originally Posted by chrism01

You've chosen a hard example there

Basically systemd is a replacement for the old SysV init+startup scripts.
Its a large binary, whereas the old scripts are shell text - this worries many people....

There is indeed some hard discussions as to whether its a good idea. However, it looks like most distros are going with it (atm) eg the latest RHEL (v7) uses it, so derivatives will as well.
See this https://wiki.freedesktop.org/www/Software/systemd/

HTH

Really off-topic, but here is a detailed list of the reasons for the move to systemd in Archlinux: https://bbs.archlinux.org/viewtopic....49530#p1149530.

Doug G · 12-01-2015, 11:59 PM

If you're using a yum/dnf distro, yum info <packagename> will give a brief synopsis of the package, and generally will give you a web link to the package web page.

TobiSGD · 12-02-2015, 05:12 AM

Assuming that you use a Debian/Ubuntu derived distro (your profile shows that you use Mint), this is what I use:

Code:

>>> apt-cache show systemd
Package: systemd
Version: 215-17+deb8u2
Installed-Size: 11881
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Architecture: i386
Depends: libacl1 (>= 2.2.51-8), libaudit1 (>= 1:2.2.1), libblkid1 (>= 2.19.1), libcap2 (>= 1:2.10), libcryptsetup4 (>=
2:1.4.3), libkmod2 (>= 5~), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.1.9), libsystemd0 (= 215-17+deb8u2), util-linux (>= 2.19.1-2), mount (>= 2.21), initscripts (>= 2.88dsf-53.2), sysv-rc, udev (>= 208-8), acl, adduser, libcap2-bin
Pre-Depends: libc6 (>= 2.17), libgcrypt20 (>= 1.6.1), liblzma5 (>= 5.1.1alpha+20120614), libselinux1 (>= 1.32)
Recommends: libpam-systemd, dbus
Suggests: systemd-ui
Conflicts: klogd
Breaks: lsb-base (<< 4.1+Debian4), lvm2 (<< 2.02.104-1), systemd-shim (<< 8-2)
Description-en: system and service manager
 systemd is a replacement for sysvinit.  It is dependency-based and
 able to read the LSB init script headers in addition to parsing rcN.d
 links as hints.
 .
 It also provides process supervision using cgroups and the ability to
 not only depend on other init script being started, but also
 availability of a given mount point or dbus service.
 .
 Installing the systemd package will not switch your init system unless you
 boot with init=/bin/systemd or install systemd-sysv in addition.
Description-md5: b7cab5335af47ff49cf666299f5ca607
Homepage: http://www.freedesktop.org/wiki/Software/systemd
Section: admin
Priority: important
Filename: pool/main/s/systemd/systemd_215-17+deb8u2_i386.deb
Size: 2568036
MD5sum: ae1f6afbc0b4aa257fa5ae3495a882a7
SHA1: a8c044e8b0b25aaf47e18c661adc39ff873692fc
SHA256: ede99e927a9f5ec21718f1b9bd47ae70ee63a3e7639c20a10c4c5ee67a8229b3

jdkaye · 12-02-2015, 05:58 AM

As above:

Code:

:~$ aptitude show systemd

Description: system and service manager
 systemd is a system and service manager for Linux. It provides aggressive parallelization capabilities,
 uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps
 track of processes using Linux control groups, supports snapshotting and restoring of the system state,
 maintains mount and automount points and implements an elaborate transactional dependency-based service
 control logic. 
 
 systemd is compatible with SysV and LSB init scripts and can work as a drop-in replacement for
 sysvinit. 
 
 Installing the systemd package will not switch your init system unless you boot with init=/bin/systemd
 or install systemd-sysv in addition.

jdk

SaintDanBert · 12-14-2015, 03:59 PM

Quote:

Originally Posted by sgosnell

You could run 'man packagename' in a terminal and get lots of information about it.

Agreed -- but only after this package gets installed.

Consider any of the various linux "update manager" applications. They display a list of packages saying "{packagename} has an update or upgrade." Typically, the named package is already installed to your workstation. However, once you investigate said {packagename}, you discover that {package1}, {package2}, ... {packageN} will be installed as dependencies.
Since this is an update, it is not beyond reason that once of these dependencies has not been installed. The man can only present information about installed packages.

~~~ 0;-Dan

SaintDanBert · 12-14-2015, 04:07 PM

For chrism01 and berndbausch:
Thank you for the discussion about systemd but I needed a concrete packagename and that was the first one that came to mind.

For tobiSGD and jdkaye:
Both apt and aptitude report on installed packages rather than any random {packagename}. Of course, I could be wrong in that statement if my configuration and experience are counter to your knowledge and settings.

For Doug G:
I use Mint/*buntu and so yum does not apply to me. However, I believe that it also reports about installed packages and not any random {packagename}.

Thanks,
~~~ 0;-Dan

NGIB · 12-14-2015, 04:12 PM

My lightweight Buntu system has 1438 packages installed, many are just part of the base system. If you want total control, about all you can do is install a basic (no-x) net install system and add each package you want individually...

sgosnell · 12-14-2015, 08:11 PM

apt-cache search and apt-cache policy will give you some info about uninstalled packages. And you can read the man pages of any package on the internet.

jdkaye · 12-15-2015, 12:43 AM

Quote:

For tobiSGD and jdkaye:
Both apt and aptitude report on installed packages rather than any random {packagename}. Of course, I could be wrong in that statement if my configuration and experience are counter to your knowledge and settings.

The above statement is incorrect. I picked the midisport-firmware package at random.

Code:

~$ aptitude show midisport-firmware
Package: midisport-firmware              
New: yes
State: not installed
Version: 1.2-4
Priority: extra
Section: non-free/sound
Maintainer: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
Architecture: all
Uncompressed Size: 164 k
Depends: fxload, udev
Description: Firmware loader for M-Audio's MidiSport devices
 This package allows you to use M-Audio's USB MIDI and Audio interfaces with Linux. These devices
 require a firmware download before an operating system driver (e.g. ALSA's snd-usb-audio) can access
 them. 
 
 Supported devices: 
 * MidiSport 1x1 
 * MidiSport 2x2 
 * MidiSport 4x4 
 * MidiSport 8x8 
 * KeyStation (old models: 49, 61) 
 * Oxygen 
 * Radium49 
 * Radium61 
 * Uno 
 The loader is not required for the MidiSport 2x4 and for newer KeyStation models (49e, 61es, Pro 88).
Homepage: http://usb-midi-fw.sourceforge.net/
Tags: hardware::usb, role::data

jdk

salasi · 12-15-2015, 12:54 PM

I think this may be marginally useful to you, at best, but...

Quote:

Originally Posted by SaintDanBert

This situation presents most often after running some sort of update manager. The utility presents a list of packages that have available updates ... for example systemd. If one had no idea what that was or what was the value/purpose it is difficult to make good decisions about the effectiveness of the pending update.

As a default, if you have it, you want the up-to-date version. Certainly, if there are any security fixes in the update, not having them is dangerous. So, if you wanted it enough to have it installed, whether you made that decision or your distro made it for you, really you should want it enough to have the version without security flaws.

The only particularly obvious exception would be if some feature of the update breaks things on your system, and it is unclear how much good it does to read what features it brings; you'll read the features, decide you want them and then stuff breaks. At this point, you probably need the old package back, so you'd better hope it isn't the package manager that you've just broken (or you can easily roll back, with eg, snapshots).

Quote:

Originally Posted by SaintDanBert

[*]if you don't know that {feature-name} is and why you might want one, the description "implements {feature-name}" (or language or protocol or ...) offers little information.

That's difficult, but it is unclear what might help give you a 'just add water' solution. Just as an example, if you wanted something for networking non-Linux boxes, you might have a bit of a struggle to realise 'samba' was the thing that you wanted, because the name doesn't make it obvious. On the other hand, a bit of search-fu with words like 'networking', 'linux', 'windows', 'printing' or 'apple' ('smb' would be a bit inspired in this context - not impossible, but showing the sort of knowledge that we are presuming that you don't have, for this synthetic example) would surely find an informative page within the first few hits.

Now, if you have a good package manipulation tool, you can search in there, and even a wide search for a word like 'networking' is probably going to give you a couple of dozen hits and you are just going to have to read through them. I think (relevantly) synaptic will do this for you, and Yast (irrelevantly for someone using a Debian-derived distro) certainly will. Of course, the package manager doesn't search every possible package for Linux, but it does search the packages - installed or not - from the enabled repos.

If that doesn't do it for you, you could try the on-line 'Open Suse Build Service'.

Quote:

Originally Posted by SaintDanBert

[*]many packages are bundles of other packages without a description of their own

Well, meta-packages are a problem, but you have to look at few of the packages involved and see if they seem, relevant.

Quote:

Originally Posted by SaintDanBert

... for example systemd. If one had no idea what that was or what was the value/purpose it is difficult to make good decisions about the effectiveness of the pending update.

So, systemd is a particular problem, because it is a large, complex, and difficult-to-understand package. But, if you've got it - probably because your distro chose it- you want it up to date. Deciding that you want systemd in a non-systemd distro doesn't seem like the kind of thing that a neophyte should be doing, nor going non-systemd with a systemd distro. Possible, but not a project for someone who doesn't know which package does what.

joe_2000 · 12-15-2015, 02:56 PM

When I first started using Linux (that was with Ubuntu 9.10 at the time) I found the Software Center very useful and intuitive for package exploration. There is an equivalent in Mint that works just as well.
More often than not, the descriptions in there have a link pointing to project homepages.

After using Linux for a while you start getting a feeling for what packages are relevant for you and which of those are packages representing programs you directly interact with.
The vast majority / other packages are part of the base system and / or dependencies and you really only want them to be reasonably up to date and in sync with the programs using them.

To be honest, in Debian-land (including the *buntus and Mints) I have pretty much adopted a fire-and-forget upgrade mentality... and never had any issues with it.
(Debian Unstable - based distros being an exception to this rule)