Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Feb 2024 08:16:23 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Rozhuk Ivan <rozhuk.im@gmail.com>
Cc:        aryehfriedman@gmail.com, FreeBSD Mailing List <freebsd-ports@freebsd.org>
Subject:   Re: FreeBSD ports community is broken [port building configuration notes]
Message-ID:  <8C4AB1AF-139D-4144-867C-6AD1AE1E1307@yahoo.com>
In-Reply-To: <20240219104333.6ecff336@rimwks.local>
References:  <87B38D6C-1D83-4158-B03B-F4C8EA396DD1.ref@yahoo.com> <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> <20240219104333.6ecff336@rimwks.local>

next in thread | previous in thread | raw e-mail | index | archive | help


On Feb 19, 2024, at 00:43, Rozhuk Ivan <rozhuk.im@gmail.com> wrote:

> On Sun, 18 Feb 2024 08:52:55 -0800
> Mark Millard <marklmi@yahoo.com> wrote:
> 
>>> It should not require
>>> prodiere running on a supermassive machine to work (in many cases
>>> portmaster and make install recursion fail where prodiere works).  
>> 
>> As for configuring for small, slow systems relative to
>> resource use, I provide some settings that I've
>> historically used below. Then I have some other notes
>> after that material.
> 
> 
> I wrote about the fact that it is bad to demand a poudriere and use
> its absence as an argument.

I did not reply to your message(s) about such but to someone
else's message about specific points they referenced.

Do not take my previous notes as any sort of response to your
prior material.

> From my point of view, Poudriere is a tool that FreeBSD Foundation wrote
> for themselves and those who want to assemble the entire port of ports.

[This is the primary point I'm directly addressing in
this reply. My reply is primarily just a contrast with
part of my usage pattern.]

I use poudriere for multiple platforms, but the number of
packages that end up in the likes of a:

/usr/local/poudriere/data/packages/main-*-default/All/

varies from under 300 to around 600, far less than the
34000+ packages involved in a from scratch "bulk -a".

[I ignore here rare "bulk -a" builds as part of some
testing activity. I do not use the packages such builds
create.]

>> As far as more ports building in poudriere than in
>> "portmaster and make install recursion" in other
>> respects than resources: it is easier to make ports
>> build in poudriere. It provides the simpler/cleaner
>> context for the individual builders. More things
>> lead to failure outside poudriere that are just not
>> issues when poudriere is used so more care is needed
>> setting up the ports for the likes of portmaster use.
>> (And, yes, I used to use portmaster.) The required
>> range of testing contexts is wider for use of the
>> likes of portmaster to know that the port build will
>> just work in the full range of contexts.
>> 
>> Such issues adds to the port maintainer/committer
>> development burdens when portmaster or the like are
>> the target level/type of support.
> 
> 
> This topic is not about the assembly of ports, it is about
> problems in the community of people.

I did not reply to your message(s) about such but to someone
else's message about specific points they referenced.

Do not take my previous notes as any sort of response to your
prior material.

> Poudriere is useless when for 1.5 months they cannot correct
> the work of a key dependence.

[This is the secondary point I'm directly addressing in
this reply.]

Poudriere was useful for my purposes the whole time. The context
with the problem was narrower and my activity did not overlap
with where the problem was.

The wording is overly wide in its span relative to poudriere.

> Poudriere is useless when the functionality you need is not
> accepted simply because one person wished.

I did not reply to your message(s) about such but to someone
else's message about specific points they referenced.

Do not take my previous notes as any sort of response to your
prior material.

===
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C4AB1AF-139D-4144-867C-6AD1AE1E1307>