poudriere merging multiple ports trees

Russell L. Carter rcarter at pinyon.org
Mon Jan 25 14:09:08 UTC 2021


On 1/25/21 12:19 AM, Guido Falsi wrote:
> On 25/01/21 00:24, Russell L. Carter wrote:
>> On 1/24/21 2:23 PM, Guido Falsi wrote:
>>> On 24/01/21 20:35, Russell L. Carter wrote:
>>>> Greetings, I am completely ignorant here and am looking for up to 
>>>> date advice on how to get poudriere to build and make available
>>>> package sets from multiple ports trees.  I see there is a port
>>>> "portshaker" that seems to do much of what I want.
>>>>
>>>> I can think of possible alternatives:
>>>>
>>>> I can reasonably expect to have my local ports not conflict with
>>>> already existing ports (could be a common prefix in the name).
>>>> Since I'm using git, I should be able to maintain my own branch
>>>> which layers my own ports over upstream and git pull, merge from
>>>> upstream.
>>>>
>>>> or
>>>>
>>>> I can duplicate the structure and metadata of the existing ports
>>>> tree and add my own ports and leaves in the tree. Still have to
>>>> maintain unique names.  This seems to be what portshaker does?  I
>>>> am guessing that gets me a single package repo.
>>>>
>>>> or
>>>>
>>>> Have two ports trees and generate two package repos, but then
>>>> dependencies would be redundantly built, I guess.
>>>>
>>>> What do the professionals do here?
>>>
>>> I've been using portshaker for this (ports-mgmt/portshaker) for this
>>> for a long time.
>>>
>>> But when the ports tree will be migrated to git in the near future I
>>>  plan to stop using portshakern and use a git repository forked from
>>> the main one (and syncronized to it) with feature branches for any
>>> change and some "build" branches which I checkout in poudriere and to
>>> which I merge the feature branches as needed.
>>>
>>> Git allows for such a workflow and that should also be quite less
>>> error prone.
>>>
>>> BTW I noticed poudriere performs shallow clones for git repos, so it
>>>  should not use up a lot of disk space.
>>>
>>
>> Yes, it seems obvious to me to use git for maintaining
>> the feature branches containing my ports, and as you point out
>> it makes it easy to maintain multiple feature branches
>> containing different contents.  Keeping the names disjoint will
>> prevent messy conflicts.  I am by no means a git expert and
>> I already do this all the time for other projects.
> 
> There already is a git mirror of the ports tree, so you could also start 
> doing this now. Only problem is, when the tree is converted you would 
> probably have a messy time migrating to the new tree, which, I guess, 
> will have new commit hashes, like it happened for source.
> 

Right.  I'm already on the git mirror, and I expect to have to blow it
away and reclone as I had to do with source.

The disruption of the history doesn't bother me as much as it does many
others.

Best,
Russell


More information about the freebsd-ports mailing list