From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111505 invoked by alias); 25 Jun 2015 08:59:37 -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 111487 invoked by uid 89); 25 Jun 2015 08:59:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Jun 2015 08:59:36 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 19426A80952; Thu, 25 Jun 2015 10:59:33 +0200 (CEST) Date: Thu, 25 Jun 2015 08:59:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com Subject: Re: setup Message-ID: <20150625085933.GO31223@calimero.vinschen.de> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <874mmghlf8.fsf@Rainer.invalid> <20150610080526.GC31537@calimero.vinschen.de> <871thjtq0m.fsf@Rainer.invalid> <20150610185417.GL31537@calimero.vinschen.de> <87wpzbs2yj.fsf@Rainer.invalid> <87mw060xg3.fsf@Rainer.invalid> <20150612102945.GS31537@calimero.vinschen.de> <87bngkzwki.fsf@Rainer.invalid> <20150612173704.GB28638@calimero.vinschen.de> <87ioacnag7.fsf@Rainer.invalid> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="95CBLwa+io9O2zXc" Content-Disposition: inline In-Reply-To: <87ioacnag7.fsf@Rainer.invalid> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-06/txt/msg00120.txt.bz2 --95CBLwa+io9O2zXc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4876 On Jun 24 22:00, Achim Gratz wrote: > Corinna Vinschen writes: > >> What's the expected directory structure here? > > > > In the usual case ("Install from Internet") the local package directory > > contains a separate subdir for each mirror chosen from the mirror dialo= g: > > > > Local package directory > > | > > +-> Mirror1 subdir > > | | > > | +-> x86 > > | | | > > | | +-> setup.ini > > | | > > | +-> x86_64 > > | | > > | +-> setup.ini > > | > > +-> Mirror2 subdir > > | | > > | +-> x86 > > | | | > > | | +-> setup.ini > > | | > > | +-> x86_64 > > | | > > | +-> setup.ini > > . > > . > > . >=20 > I've looked at what the original code was doing (or what I think it was > doing). Besides the case that you show, it would also find a setup.ini > if the local directory was set one or two levels down (into the mirror > level or the architectire subtree level, respectively). The problem is that the existing algorithm is rather dump. The recursive search class is, IMHO, C++ at its worst. In fact, the original code (you should be able to look this up in the git history if I didn't screw this up during the cvs->git move) didn't stop at the 2nd level but searched the whole tree below the local package dir. I added the "search only two levels" at one point as a band-aid since I wasn't sure if ripping out the class wouldn't break anything. Having said that, any more intelligent algorithm searching only where it actually makes sense, would be real progress. More C than C++ wouldn't hurt either. > In the latter > case, the local directory was required to have its last component the > correct architecture. I think I have cooked up a solution to do this > (not yet fully implemented nor tested), but the code would be cleaner if > the local package directory would never be at the same level where > setup.ini resides (which necessitates to extract the last path component > and check for the correct architecture). I'm not sure I understand what you're saying. Setup.ini should never be at the local package directory level is my understanding. Local package directory is either a local mirror, in which case you'd have to expect this structure: Local MIRROR directory | +-> x86 | | | +-> setup.ini | +-> x86_64 | | | +-> setup.ini | +-> noarch (just would be nice at one point) or it's the normal user case of a local package directory containing (partial) mirrors of Cygwin mirrors as outlined in my original ASCII art. AFAICS we can expect these two and don't have to care for anything else. > So the question is if that was maybe an accidental feature that can be > removed? The code would become a bit cleaner. If anybody was using it > inadvertently, they just need to remove that last component form the > local package directory, so there's no loss of functionality that I can > see. >=20 > There's another accidental feature (I think) in that old code in that > you could mix two package sources at different levels like this: >=20 > > Local package directory (ending in /x86) ^^^^^^^^^^^^^^^^ This is a no-no > > | > > +-> Mirror1 subdir > > | | > > | +-> x86 > > | | | > > | | +-> setup.ini ^^^^^^^^^^^^^ Downloading from mirrors > > | | > > | +-> x86_64 > > | | > > | +-> setup.ini > > +-> x86 > > | | > > | +-> setup.ini ^^^^^^^^^^^^^ Local package directory is a mirror itself > > | > > +-> setup.ini ^^^^^^^^^ Ignore this > and setup-x86.exe would find three setup.ini. I think that's a mistake It was not a mistake a couple of years ago. Keep in mind that we originally only had one platform and no x86 and x86_64 subdirs. Therefore, finding the top-level setup.ini (the bottom one in your ASCII art) was required when we moved to a multi-arch approach. However. - It would only have been correct for x86, never for x86_64. - It's absolutely outdated these days. > and I would want to truncate the search at the first level a setup.ini > has been found (in this example only the one in the local package > directory). Strictly, we don't have to support updates from the old non-multi-arch setup anymore, therefore any top-level setup.ini can be ignored. So, from my POV, the search should ideally work like this: - Start at Local package directory. - Look if a $arch subdir exists. If so, does it have setup.ini? If so collect it and stop here. - Otherwise search all immediate subdirs. Look if they have a $arch subdir. If so, does it have setup.ini? If so, collect it. Does that make sense? Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --95CBLwa+io9O2zXc Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVi8L1AAoJEPU2Bp2uRE+gVAMQAIlZNtq/lQS5aSe6tSAKi+Pa As/r4sCzhcl+vS+sV/Swuv54JpHWrWmzzGXQbe9AJuxmI48QvUJyIlUXNK2F07fM 5CIsUooQFVUXO5+jopfWNrwoC454Uvu9AqZd/19KUPr/5ryclIekVrmachIyjt4/ CA76B4u9hWHzSmkO4xdBeXDOF5Uox4RzkJ9FDubfgS1ONe6lcH0A8O2+Rg5lsuzl 47IqImMs5NLzjGup21BENZVb3JJj5629lyLI4rGHw35pK3kN3D2UTMuSRM4+iTc7 7oYmC8lNUwER6Y6ud36rXKdKJ5iswtvjRDECFZomGZ6sgVreY6vC6R18udoCQ75g 1JLWmZhGyczfpbE+Pl2eFOAm9vaakmERVdyIKm/TusBEb/E+rjMmKxKAmscI64Kt KX3iYsqquTFb5+MvFtj7cbQFYZ6yTVc5SnYlwgQmeEgVSEtEKlg6rmgjHoklNsc9 W1TrgCxurnGsRPgjAbjGDNuz9jxvOQuvKLRYBlUj2Ww5kdKYDQsCZAxDQsWm+yta mYB0E+KUC1xME2BHXeQcVRMJ0ZNpP+0UJ/hG7G5eQ/5KBBEBnFWlfn1MSzSAlJxp F9SXF/flmoA24MypbCBa3cvYvBbagZSdvTGg0pwz+zTShOCOQST4gUGEcthaRC6j ktH4bpIUFrnVYJqpYN0G =K5kn -----END PGP SIGNATURE----- --95CBLwa+io9O2zXc--