From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34088 invoked by alias); 2 Jun 2015 16:24:39 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 34078 invoked by uid 89); 2 Jun 2015 16:24:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-in-05.arcor-online.net Received: from mail-in-05.arcor-online.net (HELO mail-in-05.arcor-online.net) (151.189.21.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 02 Jun 2015 16:24:36 +0000 Received: from mail-in-20-z2.arcor-online.net (mail-in-20-z2.arcor-online.net [151.189.8.85]) by mx.arcor.de (Postfix) with ESMTP id 3m1Jc075Qsz71nS for ; Tue, 2 Jun 2015 18:24:32 +0200 (CEST) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-20-z2.arcor-online.net (Postfix) with ESMTP id EF8406FC6CD for ; Tue, 2 Jun 2015 18:24:32 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-08.arcor-online.net 3m1Jc05qQTzY55x Received: from Gertrud (p54B474C8.dip0.t-ipconnect.de [84.180.116.200]) (Authenticated sender: stromeko@arcor.de) by mail-in-08.arcor-online.net (Postfix) with ESMTPSA id 3m1Jc05qQTzY55x for ; Tue, 2 Jun 2015 18:24:32 +0200 (CEST) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: setup References: <87382fdvjp.fsf@Rainer.invalid> <20150531102421.GB4329@calimero.vinschen.de> <878uc3l2my.fsf@Rainer.invalid> <20150601183432.GT4308@calimero.vinschen.de> <874mmrky4e.fsf@Rainer.invalid> <20150601210617.GW4308@calimero.vinschen.de> <87wpzm664z.fsf@Rainer.invalid> <20150602082929.GA4308@calimero.vinschen.de> Date: Tue, 02 Jun 2015 16:24:00 -0000 In-Reply-To: <20150602082929.GA4308@calimero.vinschen.de> (Corinna Vinschen's message of "Tue, 2 Jun 2015 10:29:29 +0200") Message-ID: <87y4k22i4k.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-06/txt/msg00021.txt.bz2 Corinna Vinschen writes: >> Why? In any case it'd be easy enough to make it switchable. > > Transition period. We should do changes like that in two steps, first > updating to a setup which handles the new checksums, then changing the > generation of checksums to the new method. Like we did with > MD5->SHA512. It's smoother that way. It's also certainly not a bad > idea to continue supporting the older checksum methods. You're very > likely not the only person creating his/her own setup.ini files and > every change may break a script elsewhere :) Yes, but in this case you're really talking about the setup.exe side, not the generation of the setup via upset or genini (which I thought you were talking about, since that's the part implemented in Perl). If we use the SHA512: prefix then both hex and base64 encoded checksum are distinguishable easily and we might even throw in MD5 just for fun. I don't see off-hand why either upset or genini should be capable of emitting both styles into the same setup.ini, but it is easy enough to do this per setup.ini file creation by adding an option to specify which digest you want. > You seem to be doing this on a regular basis with your own scripts. Is > that right? Would you think your own method is just hacked to work, or > do you think your own ini creation scripts are clean enough to release > them to the public? No, it's fairly sophisticated already, but not yet feature-complete and requires a few clean-ups (don't they always?). > I'm asking because, right now, we're relying on a convoluted perl script > set which is hard to understand (at least for non-perl guys), is missing > comments, has no maintainer, and above all, has a questionable license. What I have is also mostly a Perl script plus a few CMD files around it, so that part likely wouldn't change. > Upset is a beast. It handles ini file creation as well as creating the > package information for https://cygwin.com/cgi-bin2/package-grep.cgi, > as well as the package upload post-processing. Since I can't even look at upset, I use genini for the initial setup.ini creation for any local packages (I have many of those). The rest of the process is taking multiple setup.ini files and rewrites them into a new one, then installs the necessary files into a staging area, which can optionally be cleaned of files not being referenced anymore after an update or change of packages to install. The staging area is then replicated onto the real installation directory. This is under control of a setup.conf file that looks more or less exactly like the name implies. You define your package sources and their dependency order (should they provide the same package, which is what happens for packages that I carry local patches for), and then list the packages you want to have available (you can inject new group names so it's easier to install via setup.exe). Dependencies are pulled in automatically and you can specify that you want an experimental or previous package instead of current. It can also automatically pull devel and debug packages into groups so that they do not clutter the install for non-developer installs and are by default available on those install that are for developers. You can also blacklist a package in some package source if you want to reverse the order just for one package or if there's a packaging error in an external package source. > I would very much appreciate if we could split these tasks into separate, > independent scripts or tools under GPL or BSD license. Well, if we keep this as a task for Perl it would make most sense to put those things into Perl modules, one per task. If a standalone script is preferred in some place we can always fatpack those modules again. > So, what about your scripts? Do you think they could be used as a > start? Do you have, perhaps, fun to rewrite the upset functionality in > a maintainable form and *gasp* maintain it? As I said, I'm coming at this from a different angle: the need to integrate multiple package sources and make a new install hierarchy that can be used locally, without being connected to the Internet and without carrying all the baggage around that a full mirror would have. Plus, I need the install to be fully scriptable to install for users that have no admin rights. The features that I'm missing is explicit version pinning (unfortunately I'll have to do some extensive changes under the hood to get rid of the current prev-curr-test structure, didn't think of that early enough) and the ability to keep different versions of an installation around. I sort of can do that already if I'm careful enough not to clean away files that are still needed, but it's too fragile even for very sparse usage, so I use the staging directory for release tests at the moment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds