[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to check Bio-Linux package selections



On 02/05/11 09:36, Andreas Tille wrote:
On Sun, May 01, 2011 at 08:03:42PM +0100, Tony Travis wrote:

I just use "dpkg" to set the selections, I then install them using:

   aptitude -f install

This is hackish anyway.

Hi, Andreas.

Yes, I know and that's why I posted here asking for advice :-)

The list of packages can be a meta-package.  You could either write one from
scratch, or modify the Debian Med blends packages.  It would not be too
difficult to unbrand or rebrand them.

Yes, I've thought of creating a meta-package - One thing that has
stopped from doing that me so far is not knowing how to create a package
dependency tree and how to prune off all the lower level dependencies
that could be installed automatically. A meta-package containing an
exhaustive list of all the required packages would not be an elegant
solution, would it?

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.

Everything else is done by apt.  If you simply build the source of the
Debian Med packages (using "make dist" in the unpackaged source tree)
after having adjusted the target distribution you get a metapackage for
Bio-Linux (because we just are using those Depends from packages which
are not yet in Debian - we call it prospective packages).  If you use a
different target distribution you will get different metapackages and
can compare their list of Recommends.  The metapackage creation process
is automated and and just includes what is in the package file of the
target distribution - so everything you might seeking for is there.
(It might make sense to remove those tasks you are not interested in
before you start make dist.)

I remember you regarded Debian as to complicated - but sometimes there
are tools which are really helpful. :-)

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.

If I understand your advice correctly, you recommend building a source deb and using that to bring any systems into compliance automatically. 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.

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.

I hope this helps to make my objectives easier to understand.

Thanks for your advice,

  Tony.


Reply to: