From Newsgroup: muc.lists.freebsd.ports
This is a multi-part message in MIME format. --------------LOzR9OtimUPu10pMvEsBMRSl
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
On 2026-07-04 11:45, Gert Doering wrote:
Hi,
On Sat, Jul 04, 2026 at 11:40:32AM +0200, Michael Grimm wrote:
Can we get databases/lmdb reverted to 0.93.5, and 1.0.0 added as a separate origin?
+1
+1 - and then depending packages can decide how they can migrate, without breaking user setups when running a naive "pkg upgrade"... (POLA).
gert
There are two different issues here, Migration and compatibility People
really need to get rid of the "I don't want to change" mindset
especially tracking head/master. POLA is not about that, we can't police upstream projects and doing forks / extensive patching isn't reasonable
and neither what any other distro / package repo does. If upstream makes changes users need to follow. We can apply POLA to projects we own but expecting that to carry out to third party is obviously out of our
hands. What we can do is however to inform about breaking changes and
try to make the migration as painless as possible. I'm not suggesting
that we knowingly should break things just to the sake of it but on the
other hand these kind of issues have occurred before and will occur from
time to time. Compatibility As Arch people have noted there also seems
to be runtime and (?) build issues, that however needs to be addressed.
Given that time frame and affected ports it's likely a better idea to
revert the commit and create a meta PR for upgrading 1.x instead of
having multiple versions in parallel.
What can we learn from this? Changelogs are important and to be fair one
could argue that this information wasn't easily obtainable / well communicated.
https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/P347LVJF4UAA3XL7D7ITJGJI54UAARXC/
https://www.lmdb.tech --> "Technical Information" (below download
button) --> More documentation --> "Upgrading From Release 0.9"
http://www.lmdb.tech/doc/upgrading.html
No CI pre commit doesn't help, "exp-run"-ish requirement/checks and
expecting a committer to have access to two different releases and at
least three arch's (amd64, aarch64 and if possible i386 (I know its
being phased out)) is a bit of a tall order, we're all humans and we can
miss things. Best regards, Daniel
--------------LOzR9OtimUPu10pMvEsBMRSl
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2026-07-04 11:45, Gert Doering
wrote:<br>
</div>
<blockquote type="cite" cite="mid:
akjWRlV1VJzDWDRb@greenie.muc.de">
<pre wrap="" class="moz-quote-pre">Hi,
On Sat, Jul 04, 2026 at 11:40:32AM +0200, Michael Grimm wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Can we get databases/lmdb reverted to 0.93.5, and 1.0.0 added as a separate origin?
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
+1
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
+1 - and then depending packages can decide how they can migrate, without breaking user setups when running a naive "pkg upgrade"... (POLA).
gert
</pre>
</blockquote>
<p><span style="white-space: pre-wrap">There are two different issues here,
Migration and compatibility
People really need to get rid of the "I don't want to change" mindset especially tracking head/master. </span><span
style="white-space: pre-wrap">POLA is not about that, we can't police upstream projects and doing forks / extensive patching isn't reasonable and neither what any other distro / package repo does. </span><span
style="white-space: pre-wrap">If upstream makes changes users need to follow. We can apply POLA to projects we own but expecting that to carry out to third party is obviously out of our hands. What we can do is however to inform about breaking changes and try to make the migration as painless as possible. I'm not suggesting that we knowingly should break things just to the sake of it but on the other hand these kind of issues have occurred before and will occur from time to time.
Compatibility
As Arch people have noted there also seems to be runtime and (?) build issues, that however needs to be addressed. Given that time frame and affected ports it's likely a better idea to revert the commit and create a meta PR for upgrading 1.x instead of having multiple versions in parallel.</span></p>
<p><span style="white-space: pre-wrap">What can we learn from this? Changelogs are important and to be fair one could argue that this information wasn't easily obtainable / well communicated.
</span></p>
<p><span style="white-space: pre-wrap"><a class="moz-txt-link-freetext" href="
https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/P347LVJF4UAA3XL7D7ITJGJI54UAARXC/">https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/P347LVJF4UAA3XL7D7ITJGJI54UAARXC/</a>
<a class="moz-txt-link-freetext" href="
https://www.lmdb.tech">https://www.lmdb.tech</a> --> "Technical Information" (below download button) --> More documentation --> "Upgrading From Release 0.9"</span><span
style="white-space: pre-wrap">
<a class="moz-txt-link-freetext" href="
http://www.lmdb.tech/doc/upgrading.html">http://www.lmdb.tech/doc/upgrading.html</a></span></p>
<p><span style="white-space: pre-wrap">No CI pre commit </span><span
style="white-space: pre-wrap">doesn't help</span><span
style="white-space: pre-wrap">, "exp-run"-ish requirement/checks and expecting a committer to have access to two different releases and at least three arch's (amd64, aarch64 and if possible </span><span
style="white-space: pre-wrap">i386 (I know its being phased out)</span><span
style="white-space: pre-wrap"> ) is a bit of a tall order, we're all humans and we can miss things.
Best regards,
Daniel</span></p>
</body>
</html>
--------------LOzR9OtimUPu10pMvEsBMRSl--
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to
news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2