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

Eli Schwartz eschwartz at archlinux.org
Tue Jan 15 14:03:26 UTC 2019


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.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-projects/attachments/20190115/64f4c106/attachment.asc>


More information about the arch-projects mailing list