[RFC] Why FreeBSD ports should have branches by OS version

[scratch65535 at att.net]

On Tue, 27 Jun 2017 18:16:01 -0500, Mark Linimon
<linimon at lonesome.com> wrote:

>On Tue, Jun 27, 2017 at 04:53:36PM -0400, scratch65535 at att.net wrote:
>> Since that's what I integrate for my dev use, I'd be happy to
>> take a zero'th-order cut at defining it, if nobody else wants to.
>
>Fine.  See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what
>I use.  I'm not particularly interested in maintaining it as a general
>set of files, but if someone can build on it, fine.

Okay, I'll hae a keik.

>
>> By "unnecessary", Mark, I mean the fact that the bits are not
>> controlled locally, and thus potentially change from moment to
>> moment such that it's impossible to guarantee that two people
>> building the same app with the same options on two different
>> days, or even hours, will get the same result.
>
>I don't understand this.
>
>The distinfo mechanism is the solution for this problem for released
>code.
>
>If people are relying on "whatever is in git at the moment" to
>mean "release", well then that's upstream not understanding what
>is meant by "release".  Either educated them or fork their code
>and become the new upstream.

No, I'm talking about how when trying to build a port, even if
using only the defaults, the process often fails to run to
completion.  

And the failure is nearly always because some glop of bits being
fetched from godknowswhere.edu has gone missing, or has been
upped and is now the wrong version as far as the makefile is
concerned, or has some other problem.  

Since I believe that 90% or more of our maintainers are
conscientious and build at least the default config, I can only
suppose, when the make fails, that somebody over at
godknowswhere.edu decided to do something ad-hoc, and that
"something" broke the build.  This happens so often that I don't
even try to build from ports any more ---my own work already
supplies more craziness than I can use.

>
>> Switching to a central repository model, where the bits are
>> fetched from around the globe only once per cycle, sanitised, and
>> thereafter read only from the repository, would drop the number
>> of file-not-founds and wrong-versions down pretty close to zero.
>
>Again, I simply don't understand this.

If we controlled the bits from which ports were built, then
nobody (I hope!!) would be changing them in an ad-hoc way, which
*should* make every build run to completion without
file-not-found etc.

>
>> >No one has ever done the work on "most minimal set of dependencies"
>> >in the ports tree -- and that's because it's hard work.  Add to that
>> >the fact that the technology has never supported partial checkouts
>> >and it complicates things.
>> 
>> No argument from me!   IMO a big contributor to the problem is
>> that the bits haven't been normalised and integrated into
>> libraries.  So the process is frankensteinean:  odds and bobs
>> dredged up wherever they can be found and stuck together in hope
>> that they'll cooperate.
>
>And this is where the hard work lies.
>
>By comparison, defining "which ports are canonical" is easy.
>
>IMHO.

I can only repeat that you'll get no argument from me! 

But that's the basic advantage of libraries:  do the hard work
once, benefit from it forever (fsvo "once" and "forever").   

Or do the work forever, and benefit each time only once.