Re: How to check Bio-Linux package selections
On Tue, May 03, 2011 at 12:15:09PM +0100, Tony Travis wrote:
>> I have no idea what you mean here. The metapackage should not contain
>> lower level dependencies - just the packages you want to install.
>
> I mean exactly what you just said: It is easy for me to create an
> exhaustive list of all the packages required. What I don't know how to
> do is 'weed out' the lower level dependencies that don't need to be in
> the meta-package. It is advice about how to do this that I'm seeking.
Just mention what highlevel packages you want to include and apt will
care for the dependencies.
> I suspecte that there might be a simpler way of doing it, which is why I
> asked. However, I seem to have failed to convey what I use my
> "dpkg-dsel" script for: I use it to compare the list of 'deb' packages
> installed on two different machines, or on one machine and a reference
> list of packages.
I think I understood what you are trying, but for your specific task
there is probably no better solution that "dpkg --[gs]et-selections".
However, my guess is that what you *finally* want to approach is to make
sure that a certain set of packages is actually installed on the target
system. For this purpose I was suggesting a solution where you simply
should create a list of packages you want to have and than just use the
tools we are providing. I can not imagine a simpler way (after thinking
about it since 11 years).
> If I understand your advice correctly, you recommend building a source
> deb and using that to bring any systems into compliance automatically.
A quite specific source deb for metapackages as it is used in Blends,
yes.
> However, one of my objectives is to monitor which packages are present
> in addition to the 'official' distribution and that is why I started to
> compare the output of "dpkg --get-selections" on different machines.
The method I suggested is perfectly able to include inofficial sources.
Your approach to "monitor" requires a second step (after monitoring you
probably want to install those missing packages, right) - but you can
simply install those packages by using the metapackage in one rush.
> One security 'audit' method is to record the files present immediately
> after installation, then monitor changes afterwards for accidental or
> deliberate changes. My strategy is to do something similar, but at a
> package level. I find this approach useful for managing the systems I am
> responsible for, but I decided to ask the Debian-Med community for
> advice about how to do this better because I am inexperienced in the
> more sophisticated use of the APT system.
>
> In particular, Manuel Prinz's post on 25/02/2011 in which he presented
> his "bioc-depends.pl" script made me realise that there are much more
> sophisticated ways of analysing the APT database that I know about.
>
> My hope was that the Debian-Med community would be able to advise me
> about how to do what I already do in a more robust and efficient way.
> Building a source deb for Bio-Linux is, indeed, one of my objectives.
> However, so is audit and security of existing systems. Verifying the
> package list, as I do, is one way of ensuring that only the packages
> that should be installed are present. It is also a way of comparing the
> installation of additional 'optional' packages on different machines.
While I have not yet tested this I would regard it a bug I would fix
soonish if it does not work: If you want to make sure that a certain
package is *not* installed you can also add Conflicts to the metapackage.
Currently nobody is using this feature and so I'm not sure whether it
works. So again: I would suggest you could clone the source of the
debian-med package (or rather check out)
svn://svn.debian.org/svn/blends/projects/med/trunk/debian-med/
remove those files from tasks you will probably not need and change
those tasks you feel a need for changing. For your purpose you might
want to add a
sources.list.<your_distribution_name>
and use <your_distribution_name> in debian/changelog as target
distribution. Then you say "make dist" and you get the source of a
Blends package which you can build using "debuild" and you are done with
your specific set of metapackages which work for
<your_distribution_name>. If you want to install packages which are not
part of <your_distribution_name> you need to configure your sources.list
on the target machine to point to a repository containing those packages
and than use
apt-get --install-suggests install <metapackagename>
which includes those extra packages.
> I hope this helps to make my objectives easier to understand.
I think I understood your objective which is only a part of the solution
you try to approach. I can not help you with your actual objective but
I hope to be able to provide a solution for your final goal.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: