Reducing the size of the ports tree (brainstorm v2)

[Bartek Rutkowski]

On Fri, Nov 7, 2014 at 9:15 PM, Jeffrey Bouquet via freebsd-ports
<freebsd-ports at freebsd.org> wrote:
>
> On 11/07/14 10:32, Bartek Rutkowski wrote:
>> On Fri, Nov 7, 2014 at 6:47 PM, Chris H <bsd-lists at bsdforge.com> wrote:
>>> On Fri, 7 Nov 2014 09:08:28 +0000 Bartek Rutkowski <robak at freebsd.org> wrote
>>>
>>>> On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin <bapt at freebsd.org> wrote:
>>>>> 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 :)
>>>>>
>>>>> regards,
>>>>> Bapt
>>>> At first I liked the idea, since I was wondering on my own if
>>>> pkg-descr and distinfo couldnt be simply part of the Makefile. In vast
>>>> majority of cases that would look good and wouldnt introduce too much
>>>> content into existing Makefiles. There are ports like www/nginx or
>>>> www/tengine that have enourmous distinfo files with number of entries
>>>> that would ruin readability of their Makefiles, but so far I havent
>>>> seen too many of these so I suppose they'd be the liveable drawbacks
>>>> of new approach.
>>>>
>>>> However, after reading this discussion and some more tinkering about
>>>> the idea I changed my mind - if the goal of current pkg&ports
>>>> activities is to make the pkg the default way of installing packages
>>>> and 'deprecate' ports when that happens,
>>> Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the
>>> intended result of the introduction of pkg(8). That would be a
>>> _horrible_ decision. For more reasons than I can list in a mailing
>>> list reply. Honestly. If this is true, has any real thought gone into
>>> the potential consequences resulting from this? We're not just talking
>>> about the affects on "geeks", and "hobbyists" here. We're talking about
>>> Shops, and Businesses that create specific products, for specific needs,
>>> and chose *BSD for what at least _was_ the freedom, and amount of
>>> _choices_ it offered. Making it, by comparison, more _flexible_ than
>>> it's alternatives. You'll effectively eliminate that market, traveling
>>> in the direction you appear to be going.
>>> If what I understand you to be saying is true. It appears FreeBSD is
>>> simply looking to parrot Linux, and relinquish "The power to serve".
>>> In exchange for competing for a strictly Desktop market. If true.
>>> This will mark a very dark year in history, for FreeBSD.
>>>
>>> Sincerely,
>>>  Disappointed.
>> I think we've a little  misunderstanding here. At no point I've said
>> nor heard that ports are about to be eliminated. I did hovewer heard
>> that the goal is to deprecate them, as in, encourage users to move to
>> pkg entirely
> "Please explain [ not directed to THIS post,  but to the
> THREAD maybe... ] the narrowing-of-choice encouragement reasons"
>
> I am trying triply to politely address the issues and apologize in
> advance for any perceived disrespect to the points I am directly
> replying to...
>> , once pkg is a viable ports replacement,
> Once upon a time /var/db/pkg and upstream .tbz served as a "pkg"..
> that is, a tracking of ports, and a prebuilt subset of ports.  Nowhere did I
> ever imagine that a replacment for /var/db/pkg would encourage the non
> use, replacement, deprecation, discouragement, ...
>
> Again, with apologies.
>
>>  and to make that
>> a default way to install/maintain software on FreeBSD.
> If that existed before portmaster, portupgrade  were written, how would they
> have come into existence?
>
> How about "a convenient and reliable" ??   More below...
>>  At the end, it
>> would be very hard to 'eliminate' ports, since we still have to
>> generate the packages with something, dont we?
> Spot on.
> Not only that...  I always thought ports were FreeBSD's
> strong point.  Maintainers, ... innovations... new scripts... new
> categories...
>
>>  ;) Even said that, I
>> could be completely wrong here, misunderstood someone else and so on,
>> and by no means this discussion is a statement of what is going on to
>> happen with ports/pkg oficially, so, to quote D. Adams: DON'T PANIC.
> To reiterate, to me, this "reducing the size" method seems non-trivial,
> and not without consequence.
> .... from what I have read.
>
> However, into the thread have appeared other alarming concepts...
>
>
>
>
>
>
>
> WHAT
> IF it was found that eight (typically) files rather than four
> (typically)  eventually made pkg more reliable?
>
>
>
>
>
> Meanwhile
>
> I've one machine with a large local.sqlite that won't install one (remotely)
> ANY  port without
> wanting to install irrelevant ones I had just deleted
> [ not entirely... sometimes
> pkg install port
> pkg install port
> pkg install port   <<   the third one fails in that it wants to
>       install extra ports... The first two no problem...
> ]
> That happened two or three times.
>
>
> , and upon which, [since pkg2ng
> was put into place upon it ]...
> appears a segmentation fault, that is terse (no known cause, no known
> effect, just
> a message from the shell) when starting to build a port...   and
> sometimes indicates
> a port not present unless one desinstalls it from the port, in which
> case pkg knew it
> to be there.  Seems unreliable vs /var/db/pkg + portmaster
> + portupgrade  + portmanager + another local one
> I had written... [2004-2014 ...]   I've stopped using ports or packages
> on that machine,
> for the time being...  the former because it is not a primary machine,
> the latter because
> it is not a primary machine and I am out of time to test a new pkg
> install in the
> near term...
>
> The local.sqlite was too large to email upstream for debugging.
> pkg from ports makes its own upgrade problematic... depending upon itself.
>
> etc etc..
>> :)
>>
>> Kind regards,
>> Bartek Rutkowski
>>
>>>> then the amount of work and
>>>> the risk of breaking things by doing this ports improvement outweights
>>>> its benefits. At this point I'd much rather like us to concentrate on
>>>> making pkg a perfect replacement
> as in, make the errors above impossible in some way or another. Before
> wholesale changes to the ports tree...
>
>
>>>> (I am mostly thinking about being
>>>> able to package base for stripped down FreeBSD builds and pkg
>>>> 'flavours' that would allow me install packages with custom options,
>>>> like ports) and hold off making any changes to ports until we can
>>>> safely state that 'pkg is the way to go for 99% of FreeBSD users and
>>>> ports are for that 1% of package builders, nerds, tinkerers' etc.,
> ports a feature not a bug,
> packages a feature not a bug...
>>>> " 99 percent can safely just use packages"
>
>>>> unless we simply cant move forward without some change.
>
> Dreading wholesole, sometimes even minor, port changes
>
>>>>  And just to be
>>>> sure, I am not against improving ports,
>
> My humble opinion, with all due respect,
> this particular thread introduces a non-forward-thinking
> port revision... I had ideas for more files rather than fewer.
>>>>  but rather about making better
>>>> choice of where to put our limited resources
> My humble opinion, again, I thought we had no resources to spare for
> the time being...
>
>>>>  - I am supper happy to
>>>> get back to this discussion
> Not so here.  I dislike posting contrary opinions.
>>>>  once we can replace ports with pkg :)
> Please explain replacement.  Once again.  Ports, a feature not a bug.
> Packages
> a feature not a bug.  [ I could email "ports!" to a linux a windows
> user... I could
> emal "packages!" to a linux a windows user.  Why would I email... "Our ports
> were once a shining point, but are not any longer recommended..."
>

Apologies, but I will refrain from answering to anything you've
written and/or asked about because, with all due respect, your train
of thoughts or wording (and strange formatting too) renders your
message extremely hard to read not mentioning to understand it as you
would like it to be understood, at least for such non-native english
speaker as myself.

Kind regards,
Bartek Rutkowski