The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

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

"autoinstall" with debian



I've at last been able to devote some time to working out an autoinstall
environment for debian - at first there were too many other demands in
my work environment, and then I got caught up in trying to swallow all
the water gushing from the debian e-mail hose.

The environment is not complete.  I have questions and comments. I've
considered just blasting thru and making local changes to lots of
things, but I'm beginning to think it would make more sense to at least
-try- to get some of my requirements accounted for upstream.  This could
be said to amount to a UCI-specific debian-derived linux distribution -
but more than that I'd like to see this result in something that could
be given back to the debian project.

Sorry if any or all of this has been discussed before.  I did try to
fish around in the archives first.  This was somewhat thwarted by
www.debian.org's robots.txt, and intermittent resident search engines.

It seems a number of packages do not like to dpkg with --root or
--instdir.  I've fallen back on chroot'ing prior to dpkg'ing (so
naturally I needed to extract base1_1.tgz first), at least for the time
being.  If I compile a list of packages that are requiring the chroot,
do I have a reasonable hope of seeing them changed "RSN"?

I'm noticing that "virtual packages" and "package alternation" (perhaps
another phrase has already been coined - I mean a dependency like "a | b
| c") do much the same thing.  Would it be reasonable to drop the
"package alternation"?  Indeed, there appear to be situations where the
two are combined, like: "depends: smail | mail-transport-agent".  Is
this (or should this be) valid?  Also, are recursively defined virtual
packages legal (and should they be)?

I'm looking for something that will do this sort of thing
-non-interactively-.  

If it already exists, by all means, point it out!  If not, I have a
start on one, with machine-specific profiles (which are needed for the
application at hand).

I'm finding that a small number of packages give errors while
configuring themselves, even with the chroot.  I could list these too... 

Is there an existing facility for -not- starting up daemons while
installing?  Aside from temporarily linking start-stop-daemon to
/bin/true?

How does debian keep track of which packages are currently installed? 
IE, I'm needing to install (under /a) some packages that have
interactive postconfiguration, and I need to do this all
noninteractively.  Barring getting a non-interactive postconfig for
every package (my preference, but not necessarily realistic in
a shortish time frame) I'd like to just --extract these, configure them
with a locally-provided script, and "do the magic" to tell debian the
packages have been configured.  What is "that magic"?

This -was- discussed recently, but I'm running up against a related
issue: some symlinks are absolute, which are giving me headaches when
trying to, EG, use /a/usr/bin/awk - because that points off to two
different absolute pathnames.  Could we perhaps reopen the
absolute/relative symlink discussion with this in mind?  If the links
aren't changed in the packages, I'll probably have to make them relative
symlinks at UCI.  Or slurp still more executables into the install
environment...  which increases maintenance.  On the "other vendor"
autoinstalls I've set up, it was usually most convenient to fall back on
/a/usr/bin (and similar) after a certain stage.  (The exception was
SunOS 4.1.x, because the karch stuff was so simple, and the diskless
boot was a quite complete environment - but with debian, I'm booting
from a single floppy into a ramdisk :)

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com