From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13148 invoked by alias); 8 Apr 2019 19:04:40 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 13134 invoked by uid 89); 8 Apr 2019 19:04:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=HX-Languages-Length:4284, customizations X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Apr 2019 19:04:37 +0000 Received: from [192.168.1.114] ([24.64.172.44]) by shaw.ca with ESMTP id DZZKhMCYLsAGkDZZLhmx3f; Mon, 08 Apr 2019 13:04:36 -0600 Reply-To: Brian.Inglis@SystematicSw.ab.ca Subject: Re: base-files revisited To: cygwin@cygwin.com References: <87r2aczb9a.fsf@Rainer.invalid> <87ef6cz74l.fsf@Rainer.invalid> From: Brian Inglis Openpgp: preference=signencrypt Message-ID: <00663867-5c73-17ab-34e3-b3535e88e5c1@SystematicSw.ab.ca> Date: Mon, 08 Apr 2019 19:04:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87ef6cz74l.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00072.txt.bz2 On 2019-04-08 12:25, Achim Gratz wrote: > 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- 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. Adding files into defaults and skel directories are okay, just don't change the distributed files, as you *WILL* need a way to reset or bypass your local customizations, to diagnose problems against the base install on your systems. Safest way is normally to append required changes to the end of the default installed config files from a local postinstall script that checks whether the installed config file matches the default and needs the changes appended, has already had the changes appended, or has been further customized by the user. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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