ignore the patch anyway. it's far too invasive.

also, it *did* compile but it was messed up when i ran it. it compiled 
normal firefox!

i'm going to re-do it in a much more conservative way in a future attempt.

what i will do in a future re-attempt is:

* remove mozconfig from librewolf, and only use CONFIGURE_ARGS. keep it 
the same as firefox, but with librewolf hardening added

* possibly add hardening to the firefox port (in CONFIGURE_ARGS). based 
on the removed mozconfig from librewolf

* yes, move more things into www/mozilla (no www/mozilla-browser). 
perhaps conditional items in www/mozilla, e.g. check whether it is a 
browser type, and act there, rather than having www/mozilla-browser


my main concern is not simply to make librewolf maintenance easier, but 
to generally simplify all mozilla maintenance in openbsd. assimilating 
tor-browser into this newly generalised framework would also be nice, 
but i'll look into that much later and only with the blessing of the 
tor-browser port maintainer.

the other concern is this:

with a more generalised porting framework specifically for mozilla 
browsers, we could add a lot more mozilla-based browsers to openbsd 
quite easily. there are already several spins of librewolf for example. 
e.g. librewolf-hellfire



Am 02.09.26 um 08:56 schrieb Landry Breuil:
> Le Wed, Sep 02, 2026 at 08:12:53AM +0100, Leah Rowe a écrit :
>> once i'm done unifying firefox/firefox-esr/librewolf, i'm probably going to
>> target tor-browser as well.
>>
>> OpenBSD has like five different versions of the same port. It seems to me
>> that all will be more maintainable overall if they all use the same setup,
>> with each individual port only altering what it needs. It's the same concept
>> behind www/mozilla, but for browsers, hence my addition (in the WIP patch)
>> of www/mozilla-browser
> if you want to factorize things, move them to www/mozilla. that module
> evolved a lot over time and maybe needs a refactoring, i agree things
> would be more maintainable overall, but i wont have the time/resources
> to dive into this before months (eg at a hackathon where you can spend
> several consecutive hours testing all aspects), so dont hope any
> review/feedback from me on such a refactoring, unless you want to take
> maintainership of all the consumer ports.
>
> my current workflow to maintain
> firefox/thunderbird/firefox-esr/(seamonkey) works for me and i
> understand it, and i'd like to keep it this way :)

-- 
Company director, Minifree Ltd
Registered in England, No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK

• OpenPGP_0x5C654067D383B1FF.asc (3K)