X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; q=dns; s=default; b=UTwu0
	8ri8qSRPwfFEJHO4Dn47VppU6vZyWa9WaxhElWiwZDSEWt6I+bf85arDRwTuvrCW
	Pq7h9syWiAs9r9sNSkVHw7mtZTCkuVPL3H/6SOUCfN3/vCA7dmTplSu3jdnR2ly8
	AKo5AWfeJ0A0WuE+R1n1sLllOODHKUrzjfYygE=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; s=default; bh=RxnzOJHAv4z
	Kg93zApRMAd0T4aU=; b=emxbUhXAyrXKOGIe2hW5GPafxJY+UjQXr3wVvI9di3c
	Py7aSQhI7jMaHujYPTyF/RmE0rSAcIfySECGbTz1eamDJRrw+GLMLnpuhyXcP/CP
	9i9oLcpOkq+eHQPdRfGKEabeCq4PeLX0020JGa34TCa54o7lRFQ79QsE/zz6I2EQ
	=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=company, offer
X-HELO:	vsmx011.vodafonemail.xion.oxcs.net
From:	Achim Gratz <Stromeko AT nexgo DOT de>
To:	cygwin AT cygwin DOT com
Subject:	Re: base-files revisited
References:	<CAAgpg9aoVkqmxHxsEjjbYFFftrtvfVJk9HLbUKh0h1r3LgweAQ AT mail DOT gmail DOT com> <87r2aczb9a DOT fsf AT Rainer DOT invalid> <CAAgpg9Y+sxHWsFbff4YfHRqFBV38kvxSrwTDrjTSg8zPvsHsjg AT mail DOT gmail DOT com>
Date:	Mon, 08 Apr 2019 20:25:46 +0200
In-Reply-To:	<CAAgpg9Y+sxHWsFbff4YfHRqFBV38kvxSrwTDrjTSg8zPvsHsjg@mail.gmail.com> (John Morrison's message of "Mon, 8 Apr 2019 18:37:44 +0100")
Message-ID:	<87ef6cz74l.fsf@Rainer.invalid>
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version:	1.0

John Morrison writes:
> The company won't allow anything to be installed directly from the internet.
> We were going to create a local mirror repo of the things which are allowed
> to be installed along with a 'package script' which will call setup with
> the appropriate commands.

That sounds more or less exactly like my own place of work.

> The company specifics we were planning to have as another, separate, local
> 'mirror' and get setup to merge them. It works, not very pretty though. If
> you know of a better strategy I'm all ears!

What I'm doing is that I have a Perl script that is controlled by a
setup.conf file and can use any number of local repos and merge them
into a local install directory (it now also mirrors from the upstream
repos just those files I really need instead of all of them).  The
reason for doing it that way was mainly to be able to inject arbitrary
extra categories that I can then install (I have different types of
installs for different users).  I can also lock package versions for
those days when I need to delay a package update (or want to pull in a
test package).  I still plan to clean that up enough so I can release
it, but I'm continually out of round tuits on that.  I also compile my
own setup.exe and have replaced the PGP key in there plus made the
signature check mandatory so nobody can use a setup.ini I haven't
signed, which in turn means no packages I haven't put in the local repo.
The setup is also run in a way that it leaves the installation with
exactly those packages I specified for each install type, so if an
installation is downgraded it'll remove any extra or reinstall uprev
packages.

Another less intrusive option is to just place a few packages in your
mirror that "depend" on all the leaf packages you want to install and
then just let setup install that single package and pull in the actual
installation via dependencies.  That will not allow you to easily remove
packages when they are no longer needed, but if your installations
aren't expected to change that way then this works.

> They don't get a choice, although we might open the default mirror up
> sufficiently for folks to request specific additional packages added to the
> installation. Best we're allowed to offer.

That's why I'm having different install types.  The normal users don't
want or need the development tools and even among the developers only I
myself install with all the debuginfo packages and only on the package
build machine.

> I didn't think about installed last... I could get the postinstall to
> append to the actual files (/etc/defaults/skel or /etc/skel) directly...

Leave /etc/defaults alone or you defeat the detection of altered
defaults.  More generally, don't edit or overwrite files installed from
any package, as removing or re-installing the package will nix all your
changes.

> The base-files-<company> package was already adding some additional
> /etc/skel/.rc files, what I really wanted was a way of adding the to
> /etc/skel/.bashrc and /etc/skel/.inputrc so that might work.  I think some
> defaults for mintty were mentioned as well (we have fairly high spec
> monitors and everyone ends up boosting the font size).

Once you change files in /etc/skel, you are continually responsible for
them yourself.  Packages never install there directly and if they are
changed from the default they won't get touched again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -