Date: Fri, 07 Nov 2014 12:15:58 -0800 From: Jeffrey Bouquet <jeffreybouquet@yahoo.com> To: Bartek Rutkowski <robak@freebsd.org>, Chris H <bsd-lists@bsdforge.com> Cc: "ports@FreeBSD.org Ports" <ports@freebsd.org>, Baptiste Daroussin <bapt@freebsd.org> Subject: Re: Reducing the size of the ports tree (brainstorm v2) Message-ID: <545D287E.1060700@yahoo.com> In-Reply-To: <CAHcXP%2Bfe94NRBEpnYGy9Amuv_72cX==8UMK6m1pdgtv=tY9vrw@mail.gmail.com> References: <20141031185621.GC15967@ivaldir.etoilebsd.net> <CAHcXP%2Bfx8BF-OfJ%2B5gDDBPRncoKMssYyHQXeOtNkR4ToNLyPJg@mail.gmail.com> <6f0a3ce6d5370d40e4ea888c7eaf6dec@ultimatedns.net> <CAHcXP%2Bfe94NRBEpnYGy9Amuv_72cX==8UMK6m1pdgtv=tY9vrw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/07/14 10:32, Bartek Rutkowski wrote:
> On Fri, Nov 7, 2014 at 6:47 PM, Chris H <bsd-lists@bsdforge.com> wrote:
>> On Fri, 7 Nov 2014 09:08:28 +0000 Bartek Rutkowski <robak@freebsd.org> wrote
>>
>>> On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin <bapt@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..."
>>>
>>> Kind regards,
>>> Bartek Rutkowski
>>> _______________________________________________
>>> freebsd-ports@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
>>
>> _______________________________________________
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?545D287E.1060700>