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 6DA3C1382C5 for ; Tue, 16 Feb 2021 01:37:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E790BE0875; Tue, 16 Feb 2021 01:37:44 +0000 (UTC) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 5E740E0831 for ; Tue, 16 Feb 2021 01:37:44 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id jt13so14214043ejb.0 for ; Mon, 15 Feb 2021 17:37:44 -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; bh=drAVrGX2BRrHcXs6n6gg2TS9PgxTZvuZbUQ6zmCOTqU=; b=TrmAYSfmARqtNdZfb9r0UZ4fu+KZKnhbIh6yKERvTvSBqyGSeYr/7O2IbIoVdVsUC+ jc7/az9tOnjxjkrNNkCavYxMbggbfc21FgReMi3EAHXMq8eeheFaNykLSk/oEINDPQkU 8ZEef8Tm1/gEEIxDN2Auay8Ye5AirHBu7Uxlsen0P9XBwibYxD6e+sLW+7sR7rWMuz6F 37niAxLV3p05+5ec9+S4Ubgt6oqeenBFqBJmA8cxMCe0ktUcAnonIa/oeL6YTO/Fi5Rd WKtrE7NIhEj9Tf1PMpkQDylL//HF6aer87eZhsA+uq02+iD9LekJw7K/Lv1+zPVpsIGt l82Q== 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; bh=drAVrGX2BRrHcXs6n6gg2TS9PgxTZvuZbUQ6zmCOTqU=; b=G/CW6SSkRfiOJ007kx/auVPu5mpX8ABFZLZCJaD0l71XLTIGrAqe/OsW0SZkkdfQeB /L7NxObDvynZz+8P7SlVYCEEdorOGhH1lEv0cp5MstwLfMOcziscISu2EnQjuXrXOmyA Mljh/HuzBIx6COQNtPBfZXde2VmU1njPn97xPhaZ9UOKEoVHUp7DrRJaW0CdlcoQ/D9D L1JXs/jXJR0W0RG75/JH/wBJRE0GeXALcFDPOghCDWXukpTnda2OCbbmZkZf93u6auOd /lbq6vC6yT2xo7ihnwneOVwxn1hPl1/yRmxcRy2B59suZ/uI8vC7XcGSin7z/PGCUsjR pYkw== X-Gm-Message-State: AOAM530Y6gdrEK+JLX2qgZZMPPR9aKUD6Z+0TZu7FK1LkkrS0kwERJ1X kK6IdV/75ABGJjKjSebsG1S16Me54YHFo9nvwPffPgJ1p8M= X-Google-Smtp-Source: ABdhPJwgbUmuVuXQl8LFTscZStmIkR0qi1d/zic5BGiOliPHlZFaR7fA1KcG2Bv+7tKYMZ0sRR/TlTOu7AqG/S149Oc= X-Received: by 2002:a17:906:24d9:: with SMTP id f25mr16308022ejb.195.1613439462836; Mon, 15 Feb 2021 17:37:42 -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: <24819743.1r3eYUQgxm@farino> <2352535.XAFRqVoOGU@farino> In-Reply-To: <2352535.XAFRqVoOGU@farino> From: Francesco Riosa Date: Tue, 16 Feb 2021 02:37:31 +0100 Message-ID: Subject: Re: [gentoo-dev] New project: binhost To: gentoo development Content-Type: multipart/alternative; boundary="0000000000000c8cfe05bb6a26b0" X-Archives-Salt: e7a0a6bc-9a5f-4153-89e2-d991b1275ddb X-Archives-Hash: c4d02df36b38dc82c97e05eb99fe3b79 --0000000000000c8cfe05bb6a26b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Il giorno mer 10 feb 2021 alle ore 20:15 Andreas K. H=C3=BCttel < dilfridge@gentoo.org> ha scritto: > > Some ideas for portage enhancements: > > > > 1. Ability to fetch binary packages from some kind of repo. > > 2. Ability to have multiple binary packages co-exist in a repo (local > > or remote) with different build attributes (arch, USE, CFLAGS, > > DEPENDS, whatever). > > 3. Ability to pick the most appropriate binary packages to use based > > on user preferences (with a mix of hard and soft preferences). > > The more definite answer should come from Zac, but I think a good part of > this > is already implemented. :) > > kind of, from make.conf manpage: binpkg-multi-instance Enable support for multiple binary package in=E2=80=90 stances per ebuild. Having multiple instances is useful for a number of purposes, such as retaining builds that were built with different USE flags or linked against different versions of libraries. The location of any particular package within PKGDIR can be expressed as follows: ${PKGDIR}/${CATEGORY}/${PN}/${PF}-${BUILD_ID}.xpak The build-id starts at 1 for the first build of a particular ebuild, and is incremented by 1 for each new build. It is possible to share a writable PKGDIR over NFS, and locking ensures that each package added to PKGDIR will have a unique build-id. It is not necessary to migrate an exist=E2=80=90 ing PKGDIR to the new layout, since portage is ca=E2=80=90 pable of working with a mixed PKGDIR layout, where packages using the old layout are allowed to re=E2=80=90 main in place. The new PKGDIR layout is backward-compatible with binhost clients running older portage, since the file format is identical, the per-package PATH at=E2=80=90 tribute in the 'Packages' index directs them to download the file from the correct URI, and they automatically use BUILD_TIME metadata to select the latest builds. There is currently no automated way to prune old builds from PKGDIR, although it is possible to re=E2=80=90 move packages manually, and then run 'emaint --fix binhost' to update the ${PKGDIR}/Packages index. --0000000000000c8cfe05bb6a26b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Il giorno mer 10 feb 2021 alle ore 20= :15 Andreas K. H=C3=BCttel <dilf= ridge@gentoo.org> ha scritto:
> Some ideas for portage enhancements:
>
> 1.=C2=A0 Ability to fetch binary packages from some kind of repo.
> 2.=C2=A0 Ability to have multiple binary packages co-exist in a repo (= local
> or remote) with different build attributes (arch, USE, CFLAGS,
> DEPENDS, whatever).
> 3.=C2=A0 Ability to pick the most appropriate binary packages to use b= ased
> on user preferences (with a mix of hard and soft preferences).

The more definite answer should come from Zac, but I think a good part of t= his
is already implemented. :)

kind of, from make.conf= manpage:

binpkg-multi-instance

=C2=A0 Enable support for =C2= =A0multiple =C2=A0binary =C2=A0package =C2=A0in=E2=80=90
=C2=A0 stances = =C2=A0per ebuild.=C2=A0 Having multiple instances is
=C2=A0 useful for a= number of purposes, such as retaining
=C2=A0 builds that were built wit= h different USE flags or
=C2=A0 linked against different =C2=A0versions = =C2=A0of =C2=A0libraries.
=C2=A0 The =C2=A0location =C2=A0of =C2=A0any = =C2=A0particular =C2=A0package within
=C2=A0 PKGDIR can be expressed as = follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0${PKGDIR}/${CATEGORY}/${PN}/${PF= }-${BUILD_ID}.xpak

=C2=A0 The =C2=A0build-id starts at 1 for the fir= st build of a
=C2=A0 particular ebuild, and is =C2=A0incremented =C2=A0b= y =C2=A01 =C2=A0for
=C2=A0 each new build. It is possible to share a wri= table
=C2=A0 PKGDIR over NFS, and =C2=A0locking =C2=A0ensures =C2=A0that= =C2=A0each
=C2=A0 package =C2=A0 added =C2=A0to =C2=A0PKGDIR =C2=A0will= =C2=A0have =C2=A0a =C2=A0unique
=C2=A0 build-id. It is not necessary to= migrate an exist=E2=80=90
=C2=A0 ing PKGDIR to the new layout, since po= rtage is ca=E2=80=90
=C2=A0 pable of working with a mixed PKGDIR layout,= where
=C2=A0 packages =C2=A0using =C2=A0the old layout are allowed to r= e=E2=80=90
=C2=A0 main in place.

=C2=A0 The new PKGDIR layout is = backward-compatible =C2=A0with
=C2=A0 binhost =C2=A0clients =C2=A0runnin= g older portage, since the
=C2=A0 file format is identical, the per-pack= age PATH at=E2=80=90
=C2=A0 tribute =C2=A0in =C2=A0the =C2=A0'Packag= es' index directs them to
=C2=A0 download the file from the correct = URI, =C2=A0and =C2=A0they
=C2=A0 automatically =C2=A0use =C2=A0BUILD_TIM= E =C2=A0metadata to select
=C2=A0 the latest builds.

=C2=A0 There= is currently no automated way to =C2=A0prune =C2=A0old
=C2=A0 builds fr= om PKGDIR, although it is possible to re=E2=80=90
=C2=A0 move packages m= anually, and then run 'emaint --fix
=C2=A0 binhost' to update th= e ${PKGDIR}/Packages index.
=C2=A0
--0000000000000c8cfe05bb6a26b0--