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 {} \;
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b1403a.1050...@gmail.com
