From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx009.vodafonemail.xion.oxcs.net (mx009.vodafonemail.xion.oxcs.net [153.92.174.39]) by sourceware.org (Postfix) with ESMTPS id 233CE388F046 for ; Thu, 4 Jun 2020 19:22:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 233CE388F046 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexgo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Stromeko@nexgo.de Received: from vsmx002.vodafonemail.xion.oxcs.net (unknown [192.168.75.192]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTP id F2603604B56 for ; Thu, 4 Jun 2020 19:22:37 +0000 (UTC) Received: from Gertrud (unknown [91.47.56.99]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTPA id C52F8604C76 for ; Thu, 4 Jun 2020 19:22:35 +0000 (UTC) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: Packaging Perl In-Reply-To: (Jon Turney's message of "Thu, 4 Jun 2020 19:50:47 +0100") References: <877dwov45z.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Date: Thu, 04 Jun 2020 21:22:32 +0200 Message-ID: <87367ar5zb.fsf@Rainer.invalid> MIME-Version: 1.0 Content-Type: text/plain X-VADE-STATUS: LEGIT X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 19:22:41 -0000 Jon Turney writes: > I think the perl cygclass in cygport can know the perl version being > built against, and can add that to the requires? It knows the Perl version and can infer what the provide should be, yes. But for the provides to be useful in a broader sense I think we need to come up with a plan on how to record which provide(s) are present in the current installation (given that the installation might be so old by the time it gets upgraded that the current setup.ini doesn't have that bit of information anymore). > I'm not sure doing it automatically for everything is possible. It sure is, the question is how to get it into the installation with the least amount of changes. To that end, I think we'd need to plop something into the file system somewhere. I believe the plan was that provides do not create (empty) tar files or show up in the package archive, but are purely metadata on the repository side, so that'd be something that setup.exe would have to do. It might be possible to stuff it into installed.db, maybe even without changing the format version, but I'm not sure that'd work for all scenarios. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables