Use of dpkg —set-selections is brain-dead?

Prev		Next

Newsgroups:  gmane.linux.debian.user
Date:        Wed, 30 Aug 2006 18:54:00 -0500

> I've traced my problem down to the use of 'dpkg --set-selections'
> command.  As an example, I have a package named tiem-nis-client-cfg that
> sets up NIS for generic workstations.  If I understand correctly, I
> should be able to do the following:
>
>    echo "tiem-nis-client-cfg      install" | dpkg --set-selections
>
> And then, when I type 'dpkg --get-selections', I should see
> "tiem-nis-client-cfg   install" one some line in the output.

No, "dpkg —get-selections" without further arguments only lists packages that are either installed or deinstalled (but still have their config files on the system), not purged packages or those that have never been on your system, even if those packages have been selected for installation. If you run:

dpkg --get-selections tiem-nis-client-cfg

that should show that your new package has been selected for installation.

To be more explicit, "3dchess" is currently purged from my system. Now, watch and be amazed:

# dpkg --get-selections | egrep 3dchess
# dpkg --get-selections 3dchess
3dchess                                         purge
# echo '3dchess install' | dpkg --set-selections
# dpkg --get-selections | egrep 3dchess
# dpkg --get-selections 3dchess
3dchess                                         install
#

You'll note that, even after "3dchess" has been selected for installation, it will not be listed by:

dpkg --get-selections

because that doesn't list purged packages, even ones ready to be installed. Instead, you must instead explicitly write:

dpkg --get-selections 3dchess

to verify that the selection status of this package has changed.

Kevin

Use of dpkg —set-selections is brain-dead?

Now I'm getting somewhere:

:~# echo "tiem-nis-client-cfg install" | dpkg --set-selections ; echo $?
; dpkg --get-selections tiem-nis-client-cfg | grep 'tiem-nis-client-cfg' ;
echo $?
0
tiem-nis-client-cfg                             install 0

This does indeed work — my tiem-nis-client-cfg package is now shown as being slated for installation.

Which begs the question: Why doesn't 'apt-get dselect-upgrade' install the package?

I have also tried 'dselect install', but with no success. They both give the same result:

By the way, this doesn't just happen with custom packages that I have created myself, like tiem-nis-client-cfg. It's also happening with regular packages: tcpdump, apticron, mc, xbase-clients, xterm, vim-gtk, r-base, gnuplot, and many more. That's part of the reason that this is so confusing to me — there doesn't seem to be any rhyme or reason that I can make out.

Michael Peek

Use of dpkg —set-selections is brain-dead?

> Which begs the question: Why doesn't 'apt-get dselect-upgrade' install
> the package?

Does your package have any unsatisfied dependencies? They need to be scheduled for install via "dselect —set-selections", too. If you're going to go this route, you have to do all the dependency resolution manually.

This is an intentional design feature, so you can "Q" out of "dselect"'s Select step with unresolved dependencies and still have the Install step install the packages whose dependencies you *have* resolved.

If you want to install packages with automatic dependency resolution from the command line, then "apt-get install x y z" (or "aptitude install x y z") would normally be the way to go.

Kevin

Use of dpkg —set-selections is brain-dead?

>> Which begs the question: Why doesn't 'apt-get dselect-upgrade' install
>> the package?
>
> Does your package have any unsatisfied dependencies?  They need to be
> scheduled for install via "dselect --set-selections", too.  If you're
> going to go this route, you have to do all the dependency resolution
> manually.

Ah, no wonder I didn't succeeded last time. Thanks for the info Kevin.

BTW, I gave up the 'dselect —set-selections' approach long time ago.

FYI, my current approach is using a self-maintaining text DB, which lists all the packages that I need. To me, what's superior in this approach are:

It is text based, very easy to edit.
It is small. I only need to care for the most important packages. For example, I only list "gnome-core" to give me the whole gnome support. Thanks to debfoster or aptitude, they will figure out what lib or other packages are required. My currently DB hold all packages that I want but it is only 5K in size. This is much better approach for version control.
It is self-maintained. Let me explain. You can define you own level of necessity. Currently I have 3 levels of necessity in my DB. 1, essential level, tools that'd go into my USB pen. 2, necessary tools for desktop. 3, optional tools that are even unnecessary for desktop.

By self-maintained I mean you can ask the DB to give you all tools at the level you required. Eg, list all tools used in the 2nd level but not 1st. It is self-maintained because the text DB is wrapped with a Perl script.

Moreover, the level of granularity does not limited to the above 3 levels. Each individual level can have arbitrarily levels for selection. Here is part of my 1st level:

0 # 0 == essential tools, for live-CD 0 # 0. system essential tools
0.1 # 0.1. disk tools
0.1 parted dosfstools
0.1 smartmontools hdparm
0.2 # 0.2. device tools
0.2 eject vcdimager
0.2 cdrecord cdrdao dvd+rw-tools
0.2 # 0.2.  alsa-modules-2.4-k7 kernel-image-2.4-k7 0.2 alsa-oss alsa-base
alsa-utils
0.2 alsamixergui
0.3 # 0.3. system management tools
0.3 grep-dctrl debconf-utils
0.3 xosview xnetload
0.3 slocate
0.3 defoma x-ttcidfont-conf fontconfig 0.3 tmpreaper
0.3 dchroot debootstrap
0.4 # 0.4. shell & text tools
0.4 wdiff
0.4 dialog
0.4 asciidoc
[...]

All in all, you define you own level and packages, the self-maintained script will return you from the levels you required the packages that you listed.

If anyone is interested in the self-maintained DB. I'll make it available to the public somewhere.

thanks