Just the person I wanted to talk to :)

I also drive-by pinged sthen on an IRC channel last night.

Hi Landry,

First of all, thank you for taking the time with me. I've been an 
admirer of the OpenBSD project for some time, and this is my very first 
port. Now, in answer to your email,

Am 19.04.26 um 07:38 schrieb Landry Breuil:
> hi, i havent looked closely at the port (and sorry it won't make 7.9,
> too late), but just one first comment on this:
That was expected, and that's OK, I shall observe your restrictions. I 
run -current exclusively anyway, so it can go in 8.0 later, if someone 
wants it in a stable release. No worries at all.
>> * I intend to regard LibreWolf -REVISION changes as the same major version
>> in an OpenBSD context, because the OpenBSD LibreWolf package strips
>> -REVISION, so e.g. 149.0.2-2 becomes just 149.0.2 in OpenBSD. If I change
>> from e.g. -1 to -2, then I would update REVISION= in the OpenBSD port
>> Makefile, but then later if LibreWolf released LibreWolf 150, I would
>> reset/remove REVISION, then reintroducing it for 150.0.X-1, -2 -3 and so on.
>> This ensures that the LibreWolf version number on OpenBSD packages will
>> always match the Mozilla FireFox version number, and only the REVISION (e.g.
>> p1, p2, p3 etc) would potentially diverge.
> i wouldnt drop the 'upstream -REVISION', rather convert it to yet
> another dot in the version (eg ${MOZILLA_VERSION:S/-/.}) because:
> - REVISION is bumped when you change something in the port and nothing
>    changed upstream

It had not occurred to me that I might replace -x with .x in the OpenBSD 
version, hence my previous logic. However, you are quite right.

Then I shall prepare "submit2", with this change. Having e.g. 149.0.2-2 
become 149.0.2.2 is also somewhat awkward, but better than simply 
omitting it as I currently do, and it is likely the only viable solution 
within OpenBSD's ports system. The only real reason I stripped e.g. -2 
before, is that the ports system regarded -x as flavor "x", which was 
invalid.

Replacing -x with .x makes perfect sense to me. I've attached a new 
tarball, with the change you requested; it is no different than 
submit1's tarball, except that it contains these changes:

Replace dist version -x with .1 -> 
https://codeberg.org/vimuser/librewolf-openbsd-port/commit/7248483cc5b1e79427985fee2ad3a8d02ba03735

Change license to OpenBSD's preferred one -> 
https://codeberg.org/vimuser/librewolf-openbsd-port/commit/c6ba17a9d45878227aa45b750372eea3186154e1

I'm re-building this now, but I anticipate no issues. Feel free to 
review this new version at your leisure.

> generally speaking i'm not a fan of firefox forks (they can be somewhat
> PR-hostile vs upstream, which i find often unfair, but ofc i'm biaised),
> but as long as they have a proper MAINTAINER and don't get in the way of
> www/mozilla/mozilla.port.mk changes i (rarely) need to do for the other
> mozillas, that's fine to have them in the portstree. diversity is good
> for the end-user.

Yes, I've designed my port specifically to not interfere at all with 
www/mozilla or www/mozilla-firefox - I only adapt its patching and 
versioning as appropriate. If there ever comes a point where my port 
requires invasive changes to the existing mozilla ports, I would adapt 
accordingly so as to avoid this precisely. For example, if that were to 
occur, I might override a specific configuration from my port while not 
touching the other ports; in the worst-case future scenario, I could do 
away with www/mozilla as a dependency in my port, making it completely 
standalone instead (as was originally my intention).

Because LibreWolf upstream closely keeps in sync with the latest FireFox 
releases, this strategy works and causes no friction in OpenBSD. I don't 
anticipate any friction, now or in the future. LibreWolf upstream is 
quite competent and they themselves try to eliminate friction on their 
end, working closely with the FireFox upstream in parallel at all times.

And yes, I will be ten thousand percent clear:

I set MAINTAINER = Leah Rowe in my port's Makefile, because I intend to 
maintain this port long term. I shall be its maintainer. I don't expect 
anyone else to maintain this port for me, moving forward. I've recently 
decided to switch to OpenBSD as my main operating system, and I have 
more ports planned, for things I use. I  may also start fiddling with 
the base system at some point, and send patches where indicated.

As for pull requests, see: https://codeberg.org/librewolf/source/pulls

LibreWolf largely focuses on changes to FireFox in line with their main 
goal of privacy- and security-based hardening, and of course keeping in 
sync with upstream. Their actual main repository (what I just linked to) 
doesn't contain the FireFox source code at all, but rather, has a 
bootstrap script that downloads Mozilla FireFox and applies all of their 
patching, for the given supported release version. They essentially 
maintain their own analog of the ports system, though their focus is 
Linux, Windows and Mac support.

They provide regular release tarballs, built from said bootstrap script. 
This then provides the full Mozilla FireFox source code, with their 
patching and branding, and it is precisely this source code (inside 
their tarball) that I use in my port for OpenBSD. It is essentially a 
drop-in replacement for the FireFox source tarball.

In other words, LibreWolf focuses on integration with the Mozilla source 
code; changes beyond the scope of their mission might be rejected, on 
the basis that they should be sent upstream (to FireFox instead), but 
that would seem completely acceptable to me. For example, if some new 
video codec came out and someone wanted it in the browser, LibreWolf 
would likely prefer submitting that upstream (to FireFox) first, for it 
to then trickle down into their distribution.

 From OpenBSD's perspective, we observe none of this; all we care about 
is the LibreWolf tarball which is, for all intents and purposes, a 
drop-in replacement of the FireFox tarball.

This will be my focus as well, in OpenBSD, providing only the most 
conservative changes possible and staying entirely in sync with upstream 
(LibreWolf) where possible. The only changes I've made to LibreWolf are 
ones that fix the build, as in the FireFox port, or OpenBSD-specific 
preferences e.g. disabling AI by default, as in the FireFox port. A 
surgical, light-touch approach, just as OpenBSD would want.

>
> (oh and thanks for providing many details on what you changed and why,
> that greatly helps reviewing a port submission like this one)

Several people have already tried the port too, and it seems to work. 
That makes me happy.

>
> Landry

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

• librewolf.tar.xz (35K)
• OpenPGP_0x5C654067D383B1FF.asc (3K)