On 3/14/26 08:32, Norbert Grundmann wrote:
> Hello Ronald,
> 
> thanks for the comments...  :-)
> 
> I think I will take another approach to build eclipse in future on
> FreeBSD.  About 2-3 year ago I made a lot patches to make version 4.32
> work - the previous one was 4.24.  It took a lot of hours.  After months
> someone took over and created a github repository with FreeBSD stuff,
> which I took as the basis.  The maintainer of that repo also creates
> *.tar.gz files which contain a full FreeBSD compilation / package, but
> not usable the pkg way.

[My notes/questions below are general/generic, not based in a detailed
analysis of java/eclipse details.]

Such a file exists that includes the compilation/package for each and
every combination of the following? [as things stand now]:

) supported arch for the port-package
  (amd64 vs. aarch64 vs. i386 . . .)

) quarterly [2026Q1] (all but main below)
  vs. latest (all 4 of the below, including main)

) 13.5, 14.3 (14.4 next), 15.0 (15.1 next), and main [so: 16.0 for now]

Even limited to tier 1 platforms (amd64 and aarch64) that is 2*(3+4)==14
combinations that each have a separate port-package built and
distributed by the official FreeBSD build servers. Are all of those covered?

(i386 is still having port-packages built for 13.5 and 14.3 as well.
armv7 and the rest are not building such at all, according to
<https://people.freebsd.org/~dbaio/pkg-master-report.html> and what it
shows for " latest " and " quarterly ", no _ in those Set names.)

And, different FreeBSD build servers can use different versions of the
port-tree's in overlapping time frames for build activity. So each
combination can get into dealing with that type of distinction as well.

Are the *.tar.gz based on using the same OPTIONS settings as for
official builds? What about other configuration details that might
change the build results?

> So why recompile?  

See above and more later below.

> I want to take his *.tar.gz
> file, extract and do the needed post-install steps.  The end should a
> "normal" package usable for FreeBSD :-)
> 
> The first steps of this approach seems to work...  I would like to check
> before I submit and before other people would confirm, that it works.
> 
> What do you think?  This way is more easy and does not use a long
> compilation time - just seconds for download and prepare.  And it is
> less error lasting ;-)

I doubt that taking externally built binaries not built by the FreeBSD
port-package build servers from a port that uses source code would be an
acceptable security risk for the official FreeBSD ports folks to allow such.

Also, it is not obvious that an externally built port-package is always
built in a fully compatible way with the officially built dependencies
that would be involved in each and every official bulk build. A similar
point goes for various combinations listed above possibly using
different tool chains to do builds. Also, how would the update timing
manage to match with the FreeBSD build server bulk build runs for each
of those combinations listed earlier? (They various combinations are not
synchronized and, overall, span widely distinct build time frames.)

Some port-packages that have java/eclipse as a dependency may also
otherwise depend on some of the same dependencies that java/eclipse
does. Mismatched versions of those need not be coherent for overall
operation to actually run and work.

At various times, quarterly and latest need not match for what versions
of dependencies and/or tool-chains are needed.

There is a lot involved in keeping the official port-package build
combinations operational. Things to not arbitrarily mix and match in a
working way.

> 
> Of course I will depend on this github repository and data.  But that I
> did the last versions, too...
> 
> Regards, Norbert
> 
> On 3/13/26 13:52, Ronald Klop wrote:
>> Rereading your mail I saw some more concerns you mention.
>>
>> 1. When developing your port for main it can be easier to install
>> dependencies for main also. That gives consistency to what is upstream.
>> 2. As long as the maintainer of maven39 does not merge the changes to
>> the quarterly branch, you don't need to do anything for quarterly. But
>> keep the 4.38 tag unchanged in github.
>> 3. Your https://github.com/NorbertXYZ/eclipse repo has a nice
>> README.md, maybe add something similar to the eclipse-maven repo with
>> instructions to your future self on how you did things. 😀 I totally
>> recognize going back to some project years later and wondering how
>> things worked.
>>
>> If you get stuck, there are probably some people here or on java@ that
>> want to help further.
>>
>> NB: it can really help to keep ports@ in the cc:, if you want feedback
>> from others too.
>>
>> Regards,
>> Ronald.
>>
>>  
>>
>> *Van:* Norbert Grundmann <[email protected]>
>> *Datum:* vrijdag, 13 maart 2026 13:37
>> *Aan:* Ronald Klop <[email protected]>
>> *Onderwerp:* Re: Question for java/eclipse build
>>
>>     Thanks a lot :-) :-) I will see...
>>      
>>     On 3/13/26 13:35, Ronald Klop wrote:
>>
>>         Hi,
>>
>>         cc-ing ports@ back into the conversation
>>          
>>
>>         *Van:* Norbert Grundmann <[email protected]>
>>         *Datum:* vrijdag, 13 maart 2026 12:46
>>         *Aan:* Ronald Klop <[email protected]>
>>         *Onderwerp:* Re: Question for java/eclipse build
>>
>>             On 3/13/26 08:51, Ronald Klop wrote:
>>             > The java/eclipse/Makefile has this comment:
>>             >
>>             > # The github repositories.  The repository under
>>             NorbertXYZ is for a > predefined maven
>>             > # download, so the build does not need to download while
>>             do-build is > running
>>             >
>>             > I think the port needs an updated NorbertXYZ.
>>             >
>>             > Regards,
>>             > Ronald
>>
>>             Thank you - that is the reason...  I can see this in
>>             freshports on the internet...
>>
>>             But how to handle this?  So I have jails to test my
>>             eclipse on aarch64 and amd64.  It runs 14-RELEASE-p9 and
>>             uses preinstalled quaterly packages - that means also the
>>             "older" maven39 port.  My question is: if I would install
>>             the newest packages from latest - would it fix the
>>             problem?  But what happens with poudiere runs for the
>>             quaterly packages.  They would need "older" maven39, or? 
>>             and if I use software, I install packages from quaterly. 
>>             I am a bit confused about how to proceed...
>>
>>             All the best, Norbert :-)
>>
>>             -- 
>>             I love penguins at the south pole, windows in my house and
>>             apples on my tree, but not in my computer :)
>>              
>>             
>> ------------------------------------------------------------------------
>>
>>
>>
>>         Your GH_TUPLE line defines a specific tag to use, which is now
>>         the same as DISTVERSION (4.38).
>>         NorbertXYZ:eclipse-maven:${DISTVERSION}:n
>>
>>         A possible solution is to create a new tag in github (4.38_2)
>>         and use that in the main port and leave the quarterly port
>>         unchanged.
>>         NorbertXYZ:eclipse-maven:${DISTVERSION}_2:n
>>         See: https://github.com/NorbertXYZ/eclipse-maven/tags
>>
>>         I hope this helps.
>>
>>         Regards,
>>         Ronald.
>>          
>>
>>      
>>
>>     -- 
>>     I love penguins at the south pole, windows in my house and apples on my 
>> tree, but not in my computer :)
>>
>>
>>   
> 
> 
> -- 
> I love penguins at the south pole, windows in my house and apples on my tree, 
> but not in my computer :)
> 


-- 
===
Mark Millard
marklmi at yahoo.com

Reply via email to