From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7F2E4138350 for ; Tue, 11 Feb 2020 15:19:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EAF1CE08B0; Tue, 11 Feb 2020 15:18:57 +0000 (UTC) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 99D36E08A0 for ; Tue, 11 Feb 2020 15:18:57 +0000 (UTC) Received: by mail-lj1-x242.google.com with SMTP id x14so11984817ljd.13 for ; Tue, 11 Feb 2020 07:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=YpAOVdXsTvyulmSDoA4dCIgWcoVgtkc6/04yMfRB9ew=; b=isxk4txqx6j8TmJ5Uvzq1JFxGpBaQLjYZnqNRIZoiE1JnT9DfHpRcQsEHn3EL8obSA 1Ua3AcxC4wDR4biATJ5XtP3a/IcNlukdL6rLib+xPe+px8VGNFcElFg7r9UhHI/9EaHV xQwzXdnBrFkZLWPkpms0rf86XOx3i62rnrRi13YNZQkD/bRVhMZjcuskzUuDY3qq6s4l EmiG4Q2AV3Bf3FWoy/wtZdzqYd4hOcnm7swhcuBNrhkuYyhKXaBeDo2HNTSkS7ouYRJ/ OBl+0AyVgwAoTAqTkZmayYnWs4NcZQFe/qUnN85Ks1b/YocGDiwvZ26X1Uhon2choaJU G8ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=YpAOVdXsTvyulmSDoA4dCIgWcoVgtkc6/04yMfRB9ew=; b=skJFYyHItTb3vDCC212AValNqRzxIJEMZO16tSzM0pxft9ZirWaH9Dv6xE8bd/Up8C qQlYRT4+2Bd3qcr22VntdPzJ9JANYR+MZfw3DMmHZWJeLWxrjeeVK3yX1xTqFwzYQjO5 XS5X4IJiVFFQ5/dXEUjWF8HMXFIJhv4tPGrSwwu/78T0CSkZac2MEj8gf0CZ6qTDyODc 3zSJz+y3oeJ7Gri1ccbqF9Bce5yQzmL6G4b5BzD+1apmFpwYiFINODXwrCQ76gQBbb2e PT/9QpLjco8hkURhlrCAQKw2Y5+o2xOEh5pLJAiU4wmFgo91kus2MoMkeszU6MOnhULN GNPQ== X-Gm-Message-State: APjAAAWF1QsDAkQTfI+oJMPzNODqippcsiEYBLS0/xpfq+5CeCDg/402 hGW7fIXIQxrk9+qpBWE+7jhh+2U10a/ZIR7amOKN1C1OwFI= X-Google-Smtp-Source: APXvYqyDNZpHsQEe1WYaNlzToM0Co6UsgIH2/uZ8d/lR39V2UYFe+71FzBXT47EDQ1l8jn+L8RjvY8Bc98WCiDRLtco= X-Received: by 2002:a2e:99da:: with SMTP id l26mr4439894ljj.272.1581434335564; Tue, 11 Feb 2020 07:18:55 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <6ec6df8d-9006-dcca-1f41-b0f98b7f7f7c@gentoo.org> <4207106.LvFx2qVVIh@falbala> <87zhdz50d3.fsf@gentoo.org> <12449796.uLZWGnKmhe@falbala> In-Reply-To: From: Tom Gillespie Date: Tue, 11 Feb 2020 07:18:44 -0800 Message-ID: Subject: Re: [gentoo-dev] Ebuild Generators To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 94754787-7b72-46cd-96a3-09d0df123e72 X-Archives-Hash: 30b3789acbd067238fb06ae5e871c0dd For historical curiosity there was also https://github.com/domenkozar/g-pypi at one point (similar to https://github.com/rafaelmartins/g-octave). Having used g-octave, the primary issue is as Micha=C5=82 says, there are a lot of corner cases that the generation doesn't handle correctly which lead to broken ebuilds and maintenance headaches. Speaking for python, catching and correcting the use of setup_requires and other insanity visited upon us by the wonders of setuptools makes this a non-starter. If you have a set a known sane packages you could in theory write an eclass that captures the regularities of those packages, but I'm not sure eclasses are suggested for that use case. Tom On Mon, Feb 3, 2020 at 5:27 AM Micha=C5=82 G=C3=B3rny w= rote: > > On Mon, 2020-02-03 at 14:20 +0100, Gerion Entrup wrote: > > Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu: > > > Hi Gerion, > > > > > > Gerion Entrup writes: > > > > > > > > Yes, that makes a lot of sense. The R overlay follows this model= . Most > > > > > of the ebuilds are automated. When an ebuild generation fails, w= e add > > > > > the ebuild manually, understand it and then update the generator = to > > > > > cover it in the future. > > > > > > > > Is this possible in all cases? I think of adding custom patches, > > > > appropriate mapping of dependencies, check for things like desktop > > > > icon cache... > > > > > > That's too complex to handle automatically. Luckily, in R overlay, s= uch > > > packages are less than 5%. An ebuild generator is based on the > > > observation that many language-specific packages are trivial to fetch= , > > > compile and install. > > > > > > > > > I'm only "maintaining" an overlay so maybe I'm missing experie= nce > > > > > > but I often have wished a tool that automatically parses the la= nguage specific > > > > > > packaging files and is able to generate a primitive ebuild out = of that. > > > > > > Maybe it even can do this in an interactive way: > > > > > > "Hey, upstream needs the dependency 'foo'. In the Gentoo packag= es I have found > > > > > > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?" > > > > > > > > > > Yes, that's the way R overlay is working. And I have a similar p= lan and > > > > > proof-of-concept solution for the Java Maven overlay. > > > > > > > > Nice to hear. I think, it is meaningful to solve all generation wit= h one > > > > tool. Maybe it can even "recognize" the used build system and packa= ge > > > > database. Is this your plan, too? > > > > > > No, I don't think it possible as far as I can see... That would be a > > > strong AI. > > I mean only on a primitive base: > > ``` > > if link contains "pypi": > > # it's a Python package from pypi > > handle_pypi() > > elif work_tree contains "setup.py": > > # it's a Python package > > handle_generic_python() > > > > Please don't use generators for Python. You'd have to put a lot of > effort to get things right. Most of the time, you'll end up with broken > or no tests, useless deps and py2 where unnecessary. > > Creating ebuilds is not a problem. Maintaining is. Python team ended > up with lots of packages dumped by former project members or other > developers. Many of them are of very bad quality. Even those that > aren't are a maintenance burden. Removing broken and/or useless > packages is taking a lot of our time. > > -- > Best regards, > Micha=C5=82 G=C3=B3rny >