From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95337 invoked by alias); 1 May 2017 19:57:34 -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 95326 invoked by uid 89); 1 May 2017 19:57:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3740, wondering, mandate, happening X-HELO: vsmx011.vodafonemail.xion.oxcs.net Received: from vsmx011.vodafonemail.xion.oxcs.net (HELO vsmx011.vodafonemail.xion.oxcs.net) (153.92.174.89) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 May 2017 19:57:31 +0000 Received: from vsmx003.vodafonemail.xion.oxcs.net (unknown [192.168.75.197]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id 4234D3E0249 for ; Mon, 1 May 2017 19:57:31 +0000 (UTC) Received: from Gertrud (p5b2f3aed.dip0.t-ipconnect.de [91.47.58.237]) by mta-7-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 8E6A130047C for ; Mon, 1 May 2017 19:57:28 +0000 (UTC) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: noarching source packages References: <87wpa54u0a.fsf@Rainer.invalid> Date: Mon, 01 May 2017 19:57:00 -0000 In-Reply-To: (Jon Turney's message of "Mon, 1 May 2017 20:35:29 +0100") Message-ID: <87lgqg73kr.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-VADE-STATUS: LEGIT X-SW-Source: 2017-05/txt/msg00005.txt.bz2 Jon Turney writes: > What is your reason for changing the name? There shouldn't be two different naming conventions for the same purpose. So package-version-release[-purpose].tar.xz with purpose:=[source|debuginfo] would be preferrable. > I was wondering if we need to explicitly identify debuginfo archives > as a different kind of thing. Currently, debuginfo packages work just > like any other install archive, which is fine, except for perhaps they > need a separate filter in setup. They wouldn't with the above naming convention and you'd just tick another box to say you want them installed, just like sources. We might even skip the archful directories and just do [noarch|x86|x86_64] as well in the same place. >> part of them is made up again of the source files, which should be >> separated out into noarch also. > > Nice idea, but the practicalities seem complex (e.g. generated source > files needs to be treated correctly). In any case, this would seem to > be a piece of work which falls after noarching the sources. Agreed. >> I'd be hesitant to use yet another tree for this. We already have way >> too many directories that make up the repo. > > 'too many'? why? I currently have to pull the mirror through a HTTP proxy, and most of the time is spent in traversing directories. Yes, it'd be possible to determine which packages are missing and directly pull those, but I haven't got around to scripting that yet. >> The only sane way is to mandate that the packages for all arches are >> built together so that you can package the sources only once during the >> packaging step. Otherwise you either have to check that the contents > > That would seem to require a cross-compilation environment for at > least one cygwin arch, with all the dependencies available. Not necessarily. You just need to package both with the same step. But yes, cygport makes this perhaps a bit harder than it should. >> It's easy enough to branch that decision inside the cygport file and the >> only time I did that have passed now that the package content in both >> arches is almost identical. So is anybody really doing that currently? > > At the moment, nothing prevents SRC_URI and PATCH_URI depending on the > ARCH, so we just don't know. > > But this is more a question of workflow: nothing stops the maintainer > going back and changing the source package, then just rebuilding one > architecture. So just define some variable in *.cygport that says "I'm not doing any of that nonsense and want to build for two arches". Unless it's set, everything stays as it is today. > The ideal solution would be a build service which accepts a source > package and produces the install archives, but I don't see that > happening anytime soon... Me neither. >> But the real problem is that besides our own stuff some upstream sources >> are archful. > > Examples? Last I looked, it was texlive. No idea why. >> The way it would work is that setup.exe should accept both noarch and >> arch archives for the same package. It would then proceed to first >> install the noarch and then the arch part if it finds both of them. >> Incidentally, this would keep the current tree structure intact and >> allow us to freely move packages from arch to noarch and vice versa >> between different releases with no manual intervention. > > Great. I look forward to reading the patches :) You're talking about setup.exe, calm or both? I'm tied up at work for the foreseeable future, so I can't spend many cycles on it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada