Re: How to consistently install a set of packages?

[paul e condon <pec11xx@gmail.com>]

On 06/06/2013 05:03 PM, Gilles Mocellin wrote:
> Le 07/06/2013 00:22, paul e condon a écrit :
> > [...]
> > > Are there any better methods I should be aware of, to ensure that
> > > everywhere the packages are installed in the same sequence?
> > David,
> >
> > I am involved in a project that parallels your's in that it is just 
> > as 'outside the mainstream' as your's seems to be. I have found some 
> > useful features of Aptitude for building and using a personal 
> > selection of packages:
> > To generate a list of installed packages, run;
> >
> > # aptitude -F "%p %M" search "~i" | tr -s " " > /root/packages-all
> >
> > This generates a list of all installed packages, followed by ' A' if 
> > the package marked as needed by some other package.
> > Run:
> >
> > # grep -v ' A$' /root/packages-all > packages-noA
> >
> > to generate a minimum length list of packages that must be installed 
> > by Aptitude to force the installation of all packages via the 
> > dependency mechanism.
> >
> > Then to install the whole lot on a nearly naked computer, run:
> >
> > # aptitude install $(cat /root/packages-noA)
> >
> > The files are text which can be edited in vim or emacs to remove 
> > cruft that is actually on the source computer but that you really 
> > don't to be automatically propagated to all your computers.
> >
> > The order in which packages are actually install is, I think, not 
> > alphabetical. Aptitude has some internal logic that installs in an 
> > order that is defined by the dependency tree.
> >
> > On a related topic:
> > Numbering of groups depends on the order in which the named groups 
> > were created during installation of the packages. You only have one 
> > user so that one user will always have a uid==1000 on Debian. All 
> > real users in Debian also have their own group, so your gid will be 
> > gid==1000. If you list the file /etc/group, you will find gid == 1000 
> > towards the end of the list, but not at the end because /etc/group 
> > grows during install by adding new group name/gid as they are needed.
> > You say the hardware of your several computers in not identical. 
> > There will likely be differences in the dependency tree in different 
> > architectures, so there will be problems over time keeping the 
> > name/number pairs the same in different architectures and different 
> > releases. I sure the problem is solvable but the effort may be beyond 
> > what you want expend on going your own way. It does sound like an 
> > interesting way to become very familiar with the insides of Debian, 
> > and a rich source of knit-picking bug reports on the documentation ;-)
> >
> > Good Luck,
> > Paul
>
> You can have in one command what you do :
> And more, with the installed version, to be sure to install the same 
> version, even if there were updates since :
>
> # aptitude -F "%p=%V" --disable-columns search '~i!M'
>
> For the ordering problem. I dont think the solver is silly enought to  
> install in a different order the same set of packages, asuming the 
> starting state is the same of course.
In the example I gave the packages are listed in alphabetical order by 
name. I doubt very much that they can actually be each fully installed 
with all pointers to subroutines fully
bound to a actual entry point, all done in alphabetical order. I agree 
that the reality can easily be hidden, but when one chooses to break 
with the tried and true methods as David wants to do, problems arise.
> Anyway, you can change the uid/gid afeterward if they are different !
> And change the rights with a command like :
The Debian package has scripts that manipulate files in /etc/defaults 
and elsewhere in order the set up the environment such that it will 
operate in concert with the information in /etc/group as it is during 
*install* process, not as the /etc/group might exist after some 
post-install user manipulation, I believe. David may *say* he wants the 
order in some particular way, but I'm sure he also wants the system to 
function as well.

On both points, I think the installer as it exists already needs to do 
the individual steps of an install in a particular order and one of the 
early steps is to discover what that order is. David wants to have 
control over that order, which, IMHO, he will find very hard to do. As 
an example, only if one defines the meaning of 'install' to exclude the 
link-edit step of a traditional compile body of code can it be 
otherwise. Link edit, or instantiating pointer arrays can only be 
generated after it has been decided where the blocks of code will be 
placed in RAM. And this is just one of many problems.
> # find / -uid 120 -exec chown 110 {} \;
> # find / -gid 120 -exec chgrp 110 {} \;