[arch-projects] [devtools] [PATCH 1/2] arch-nspawn, mkarchroot: Allow not sharing the cache directories.

[Maarten de Vries]

The commit you linked earlier[1], is that something that will find
it's way into mainline devtools?

[1] https://github.com/eli-schwartz/devtools/commit/c0681c0ec0a93a4a4eaf9b2fd85ce48a30702a03

On Tue, 15 Jan 2019 at 15:11, Maarten de Vries <maarten at de-vri.es> wrote:
>
> On Tue, 15 Jan 2019 at 15:03, Eli Schwartz <eschwartz at archlinux.org> wrote:
> >
> > On 1/15/19 8:56 AM, Maarten de Vries wrote:
> > > On Tue, 15 Jan 2019 at 14:41, Eli Schwartz via arch-projects
> > > <arch-projects at archlinux.org> wrote:
> > >>
> > >> On 1/15/19 8:34 AM, Maarten de Vries via arch-projects wrote:
> > >>> These patches make it possible to build withouth a shared pacman cache
> > >>> using makechrootpkg. I need this myself because I'm building packages
> > >>> for different repositories where some of them contain packages with the
> > >>> same name, but different compile time configuration.
> > >>
> > >> I'd suggest using different pkgnames to be honest. :D
> > >
> > > I can see your point there, but many of the PKGBUILDs are
> > > automatically generated.
> > > It would be possible to add prefixes of course, but we'll get very
> > > long package names.
> > > And the repositories are never used together, so for the end-user it
> > > looks weird.
> >
> > Without being able to visualize what you're doing I cannot say whether
> > it makes sense to me. ¯\_(ツ)_/¯
> >
> > >>> It also allows building packages for different Arch based distros on the
> > >>> same host more easily.
> > >>
> > >> Arch Linux 32 has the same issue and solved it using this much simpler
> > >> patch:
> > >> https://github.com/eli-schwartz/devtools/commit/c0681c0ec0a93a4a4eaf9b2fd85ce48a30702a03
> > >>
> > >> The solution would then be to add the different cachedirs to the
> > >> pacman.conf you use, which is anyways going to be different due to being
> > >> i686-specific.
> > >
> > > But this will still bind a directory from the host into the container right?
> > > It would require me to create separate cache directories on the host
> > > and create matching pacman.conf files.
> > > It would indeed be a simpler patch to devtools, but the whole process is harder.
> > >
> > > I do think these patches make sense.
> >
> > You could just reuse the cache directory that is being used as the
> > custom repo itself. You could even simply use this as an additional
> > cache directory, and no packages will ever be downloaded to the main one.
>
> Hmm, that sounds useful indeed. Only problem for me here is that the
> host building the packages is not the one who stores them. Otherwise
> that would be very neat.
>
> Also, Erich makes a good point that having a persistent cache is
> indeed a good thing, also across cleaning the chroot.
>
> I suppose that maybe then these patches aren't needed at all. It might
> still be useful to have a command line argument to set the cache, but
> maintaining a modified pacman.conf isn't that problematic if I have to
> make sure the directories exist anyway.
>
> So, thanks for the quick feedback Eli and Erich, I'll solve this differently :)
>
> >
> > --
> > Eli Schwartz
> > Bug Wrangler and Trusted User
> >