Reducing the size of the ports tree (brainstorm v2)

[Matthias Andree]

Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin:
> Hi all,
> 
> tijl@ spotted an interesting point, distinfo and pkg-descr files files
> convenient are taking a lot of space for "free", we can reduce the size of the
> while ports tree by a factor 2 by simply merging them into one of the other
> files (Makefile and/or pkg-plist) from my testing it really devides
> significantly the size of the tree.
> 
> Problem is how to merge them if we want to.
> 
> What we do not want to loose:
> - Easyness of parsing distinfo
> - Easyness to get informations about the description
> 
> so far I have not been able to figure out a user friendly way
> 
> Ideas I got so far only concerns pkg-descr:
> Adding an entry in the Makefile for the WWW:
> WWW= bla
> or an entry in the plist: @www http...
> 
> for the description the Makefile is not suitable as multi line entry in
> Makefiles are painful
> Maybe a new keyword:
> @descr <<EOD
> mydesc
> in 
> multiline
> EOD
> 
> which could easily be added to the plist parser in pkg. But I'm do not find that
> very friendly in particular for make(1) to extract the data.
> 
> Concerning the distinfo I have no idea.
> 
> so this mail is a call of ideas :), if nothing nice ideas is found we will just
> do nothing here :)

My urgent recommendation is to leave it as is.  Even if it wastes 200
MB.  Space is so cheap these days it's not worth introducing new
instabilities, re-train all contributors and all that.

We haven't even shaken off all the staging and pkg fall-out, and now
we're talking about the next revolution.

And if we really decided that we want to change things, we would need
these things BEFORE the implementation:

1. a clear list of the problems.
1a. Space does not count, see above.
1b. Insufficient tools (SVN) do not count.  If the tools are bad, we
need other tools, not change our way of doing things.

2. a clear list of requirements what the solution is to achieve

3. only then can we start implementing.

What you're proposing is a solution without a clear plan of what it's
supposed to solve, and how.

And IF we still decided the current way of things is so painful we need
to do something, we should leverage some of the existing extensible
forms; XML, JSON, ... diverse other markup languages.  Let's not cook
something new on our own if we already have tools for established markup.