public inbox for gentoo-catalyst@lists.gentoo.org
 help / color / mirror / Atom feed
From: Felix Bier <Felix.Bier@rohde-schwarz.com>
To: "gentoo-catalyst@lists.gentoo.org" <gentoo-catalyst@lists.gentoo.org>
Subject: Re:  [Newsletter] Re: [gentoo-catalyst] [PATCH 2/2] Move from PORTDIR_OVERLAY to repos.conf
Date: Sun, 18 Oct 2020 13:58:01 +0000	[thread overview]
Message-ID: <f473e9d22d3cbbb99b374dd90b842e3a5b07f935.camel@rohde-schwarz.com> (raw)
In-Reply-To: <CAEdQ38E_=m2QrJ64jMXJ7BttM5mBsYTM98OKCXDVckAAB+D0Yg@mail.gmail.com>

Am Samstag, den 17.10.2020, 13:11 -0700 schrieb Matt Turner:
> On Sat, Oct 17, 2020 at 12:00 PM Felix Bier
> <Felix.Bier@rohde-schwarz.com> wrote:
> > 
> > This commit fixes the following issues:
> > 
> >   * The PORTDIR_OVERLAY variable has been deprecated by Gentoo.
> > 
> >     With this commit, the variable is no longer written to the
> >     generated make.conf. Instead, a config file
> >     /etc/portage/repos.conf/<repo-name>.conf
> >     is generated for each overlay. The repo name is read from the
> >     overlay using the portage API. Internally, portage parses
> >     metadata/layout.conf and profiles/repo_name to obtain the name.
> > 
> >     References:
> >     https://wiki.gentoo.org/wiki//etc/portage/make.conf
> >     https://wiki.gentoo.org/wiki//etc/portage/repos.conf
> > 
> >   * All overlays were copied into the same target directory. If the
> >     same file name occurred in multiple overlays, the last overlay
> >     would overwrite all previous files with this name. In
> > particular,
> >     only the metadata/layout.conf of the last overlay was retained,
> >     so it was not possible to reference the other overlays e.g. via
> >     the masters entry in the layout.conf or the portage-2 syntax
> >     for specifying a parent profile from another overlay. Also,
> >     this created problems when the overlays contained ebuilds
> >     for the same package, but with differing versions, because
> >     after copying, the target directory contained both versions of
> > the
> >     ebuild but only the manifest file of the last overlay.
> > 
> >     With this commit, each overlay is copied into a separate
> >     sub-directory, e.g. /var/gentoo/repos/local/<repo-name>/.
> >     This directory is referenced via the location entry in the
> >     generated /etc/portage/repos.conf/<repo-name>.conf.
> > ---
> 
> Hello,
> 
> Thank you for the patches. I'm happy to see them.
> 
> I cannot apply the patches however. This one in particular is badly
> line wrapped by your mail client. I tried fixing it up, but either
> failed or don't know what this is supposed to apply to.
> 
> It looks like the intention is for this to apply to the
> catalyst-3.0-stable branch since it discusses copying overlays into a
> subdirectory, rather than any mention of squashfs snapshots.
> 
> I really don't want new feature work on the catalyst-3.0-stable
> branch, for example. If that is the target, then please consider
> rebasing the work onto the master branch.
> 
> Matt

Hello Matt,
thank you for the initial review.

I'm sorry for the formatting issues, I will check my mail client's
format settings and resend the patches.

The patches are intendend for the master branch. I agree that this
feature should not be in the stable branch.

My understanding is that in the master branch, the squashfs is only
used for the main repository, whereas the overlays are still copied as
directories (in the StageBase.portage_overlay() function).

This patch only removes PORTDIR_OVERLAY, not PORTDIR, so it should not
be a problem that the main repository is squashed. I kept the helper
functions that this patch adds general, so that they can be reused for
a later PORTDIR removal, but I would prefer to do that in a separate
step.

I don't know if there are plans to also switch the overlays to
squashfs. My intuition would be that the overlays would usually be much
smaller than the main repository, so squashing them would have less
benefit. Even if there is a plan to switch the overlays to squashfs (or
bind-mounting, which I would prefer), I think my patch would still be
helpful for that, since it would not be possible to create multiple
mounts with the same target directory (such as /var/db/repo/local). So
creating subdirectories (/var/db/repo/local/overlay1,
/var/db/repo/local/overlay2 etc.) would still be needed.

Best regards,
Felix

  reply	other threads:[~2020-10-18 13:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17 19:00 [gentoo-catalyst] [PATCH 2/2] Move from PORTDIR_OVERLAY to repos.conf Felix Bier
2020-10-17 20:11 ` Matt Turner
2020-10-18 13:58   ` Felix Bier [this message]
2020-10-30 16:13     ` [Newsletter] " Matt Turner
2020-10-18 15:15 ` [gentoo-catalyst] " Felix Bier
2020-10-30 16:07   ` Matt Turner
2020-10-31 21:24     ` Brian Dolbec
2020-10-31 22:28       ` Matt Turner
2020-11-10  1:03     ` [Newsletter] " Felix Bier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f473e9d22d3cbbb99b374dd90b842e3a5b07f935.camel@rohde-schwarz.com \
    --to=felix.bier@rohde-schwarz.com \
    --cc=gentoo-catalyst@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox