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 3D376139694 for ; Mon, 5 Jun 2017 15:40:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 48F4EE0E08; Mon, 5 Jun 2017 15:40:17 +0000 (UTC) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E0D5EE0DD1 for ; Mon, 5 Jun 2017 15:40:16 +0000 (UTC) Received: by mail-oi0-x241.google.com with SMTP id f206so12694236oig.2 for ; Mon, 05 Jun 2017 08:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Xe8FB4JZeDgCQsBgtWW+mdjqRn1PIT0PTcjGx9sS9Yg=; b=K17Z3aBM8xpldlDcuknXxB15PsKv2nc8IPxA4UKYq9f5gY6voTyBADNYv0JUngUcwD W0A4iZWs/OtY/HUf2TcgXEpOdPd4jGeKgILeYAinGZO9Ywk/M81NteFjLoM9XvhWgnjT JBln38UjtMmd+ly9Hk8jTXa3Dtv/s6rOKHHyy5cfLaH9DLxfSZ/y/mjs6X9chtIQg0YX Z+ADwc4JRAi0Jds3a2zfixjufjgZqfpPznQOV08Q8H4UhWL16oliY131m4/ieybjGzWq TtMPaLx1eYNPSNuauC9uQMo4WaS0JIOWI9acAHZEwYqvCoLxJYKHGYBXgpYoez4sTGaf v2Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Xe8FB4JZeDgCQsBgtWW+mdjqRn1PIT0PTcjGx9sS9Yg=; b=DxCV1QPTbB8lrK4szBpypP5ajRDnW5rDIskpHMe33+T/5F03T/ecQrgUqoQt/DnxuS VdEEasWti1X4sYnOnQPdz7yXl/PPxk4sUpwHaUoKpm3/C3QMZ6BcTESMdP2XPjveouo2 pGRtWG9E4KJ8KYG7bbRrU8CLviKEJ3U/mBrhYmQoPg2Ah7Ppl93JWLo2yX9M/uS6UINf kHfSA1v+kCalZWw999ZnUUvh8yIRRQMB0DGRiiEbczeCQObKqAWOJZWTfsOoPbYsz7/+ AGCdAV8kUBFzZHg1x7RpZlob2UYv2wN5x1thbr2sHvkTzzXXno8RK5yLHZClAWon1GTu Cg5w== X-Gm-Message-State: AODbwcD+i3gSSKSRY/MFkNpJXs2d43JzVZslLQi01lbbPHCYeK1pV3fx 7M7//NBpdJepoEPhesQxqYqMhR6Lo9yu X-Received: by 10.157.52.221 with SMTP id t29mr12194070otd.0.1496677215776; Mon, 05 Jun 2017 08:40:15 -0700 (PDT) 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 MIME-Version: 1.0 Sender: antarus@scriptkitty.com Received: by 10.182.220.35 with HTTP; Mon, 5 Jun 2017 08:40:15 -0700 (PDT) X-Originating-IP: [2620:0:1003:1022:102a:1bfc:13e4:6fe4] In-Reply-To: <1496476708.10646.1.camel@gentoo.org> References: <20170602130903.334b0d03@katipo2.lan> <2816064.Ipx2b8F6kQ@note> <20170603023827.0d4531fa@katipo2.lan> <1496415085.16111.0.camel@gentoo.org> <20170603032221.35fd3fe4@katipo2.lan> <1496476708.10646.1.camel@gentoo.org> From: Alec Warner Date: Mon, 5 Jun 2017 11:40:15 -0400 X-Google-Sender-Auth: kK1_UjX1097yubqPr11TbvGNkck Message-ID: Subject: Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml To: Gentoo Dev Content-Type: multipart/alternative; boundary="001a11405552ca45ae05513851b1" X-Archives-Salt: 6f54ac7b-8d87-410e-9bd3-e43ff55fa8ce X-Archives-Hash: a2ee4bd11dc90c975504bcad26d41ac6 --001a11405552ca45ae05513851b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 3, 2017 at 3:58 AM, Micha=C5=82 G=C3=B3rny = wrote: > On sob, 2017-06-03 at 03:22 +1200, Kent Fredric wrote: > > On Fri, 02 Jun 2017 16:51:25 +0200 > > Micha=C5=82 G=C3=B3rny wrote: > > > > > ...so if a Gentoo package is split into 40 packages in Debian, are yo= u > > > going to list all of them? > > > > If it would be useful to do so, maybe. > > > > But its a text file, people are capable of making judgements about > > adding 3.2k of text, I hope. ( worst-case, 40 lines of 80 characters > each ) > > > > If the text at that size has a use, then, why not? > > > > As long as that 40-package example is an exceptional case, where it was > deemed > > useful, not the norm. > > It's not that exceptional in binary distributions where it's normal to > split a single source into a few dozen packages (libraries, headers, > tools, plugins...): > > https://packages.debian.org/source/sid/systemd > > and that's a small one. I guess we could avoid this if you restricted > those remotes to the source package used to build them all. > I would argue that specifying source package remotes is what should be done for every package. UI layers can use the source package remote to look up metadata for the source package and get a list of the binary packages it produces when built; maintaining this list inside of Gentoo seems ill advised. (I could perhaps be swayed by a script where you populate the source package remote and a tool fills in the binary packages as sourced from debian sid or whatever.) Do we really need to store and distribute this data though? -A > > -- > Best regards, > Micha=C5=82 G=C3=B3rny > --001a11405552ca45ae05513851b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jun 3, 2017 at 3:58 AM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org&= gt; wrote:
<= div class=3D"h5">On sob, 2017-06-03 at 03:22 +1200, Kent Fredric wrote:
> On Fri, 02 Jun 2017 16:51:25 +0200
> Micha=C5=82 G=C3=B3rny <mgorny= @gentoo.org> wrote:
>
> > ...so if a Gentoo package is split into 40 packages in Debian, ar= e you
> > going to list all of them?
>
> If it would be useful to do so, maybe.
>
> But its a text file, people are capable of making judgements about
> adding 3.2k of text, I hope. ( worst-case, 40 lines of 80 characters e= ach )
>
> If the text at that size has a use, then, why not?
>
> As long as that 40-package example is an exceptional case, where it wa= s deemed
> useful, not the norm.

It's not that exceptional in binary distributions where it&= #39;s normal to
split a single source into a few dozen packages (libraries, headers,
tools, plugins...):

https://packages.debian.org/source/sid/systemd

and that's a small one. I guess we could avoid this if you restricted those remotes to the source package used to build them all.

I would argue that specifying source package remotes i= s what should be done for every package. UI layers can use the source packa= ge remote to look up metadata for the source package and get a list of the = binary packages it produces when built; maintaining this list inside of Gen= too seems ill advised. (I could perhaps be swayed by a script where you pop= ulate the source package remote and a tool fills in the binary packages as = sourced from debian sid or whatever.)

Do we really= need to store and distribute this data though?

-A=
=C2=A0

--
Best regards,
Micha=C5=82 G=C3=B3rny

--001a11405552ca45ae05513851b1--