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

[Mark Linimon]

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.

> 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.

> 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.

> >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.

mcl