poudriere merging multiple ports trees

Guido Falsi mad at madpilot.net
Mon Jan 25 07:19:15 UTC 2021


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.

-- 
Guido Falsi <mad at madpilot.net>


More information about the freebsd-ports mailing list