Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Dec 2016 17:31:58 +0100
From:      Torsten Zuehlsdorff <tz@FreeBSD.org>
To:        marino@freebsd.org, FreeBSD Mailing List <freebsd-ports@freebsd.org>, wblock@wonkity.com
Subject:   Re: The ports collection has some serious issues
Message-ID:  <bb2515b7-4b06-d840-e370-a8a5416d8c47@FreeBSD.org>
In-Reply-To: <3cf805df-eb25-187c-8bf9-b6c2be5e977d@marino.st>
References:  <3959e18e-5819-b2c5-69a9-c71ce1282383@marino.st> <f35be27a-67b9-27a6-1350-69a65b7b9435@FreeBSD.org> <3cf805df-eb25-187c-8bf9-b6c2be5e977d@marino.st>

next in thread | previous in thread | raw e-mail | index | archive | help
On 15.12.2016 17:00, John Marino wrote:
> On 12/15/2016 09:49, Torsten Zuehlsdorff wrote:
>> On 15.12.2016 16:29, John Marino wrote:
>>>>>> Although portmaster is not releated to the FreeBSD project and is an
>>>>>> outside tool, there aren't any alternatives from the project
>>>>>> itself. So
>>>>>> use it or die. Not a nice situation.
>>>>>
>>>>> People have been trying to get portmaster deprecated and removed from
>>>>> the
>>>>> handbook but have met with resistance.
>>>>
>>>> Well, yes.  Because it works, has no dependencies, and there is no
>>>> equivalent replacement.  Except maybe portupgrade, which has legacy
>>>> problems like poor default options.
>>>
>>> Every single week, somebody falsely accuses the ports tree of being
>>> broken but the accuser is the only one with the problem.  What do they
>>> all have in common?  They are portmaster users.  I'll iterate, saying
>>> "portmaster works" means applying a very generous definition of "works".
>>
>> Not really, no. Its not every week and often there is a misuse or
>> miss-understanding of portmaster.
>
> It is every week.  Consider the FreeBSD forums as well.

No, it isn't. Lets check the history. This is just a general statement. 
portmaster was added 2006 and the portstree startet in 1994.

Yes, there are emotions in discussions and they are really needed to 
drive things, but we need to ensure to drive in the right direction.

> "misuse" and "misunderstanding" failures are attributed to the tool.
> Let's stop making excuses for portmaster.  It is what it is and we've
> had years to evaluate it.

I'm with you at this point. portmaster is incredible complex and hard to 
understand. Therefore it is easy to misue or to misunderstand.

>> With an argument like this you can also state there is every week a
>> falsely accuse, because of poudriere. This would also be true (and is).
>
> I couldn't state that accurately.  I can't recall any misuse reports
> (and I can't come up with a feasible case in my head right now)

I could. My colleague did some of them. :D Even i generate some of them.

>>>>> The recommended replacements are ports-mgmt/synth and
>>>>> ports-mgmt/poudriere.
>>>>> These build an entire package repository that the pkg tool can use
>>>>> but they
>>>>> do so in clean chrooted environments, and rebuild everything that's
>>>>> required
>>>>> to keep a consistent ABI. Synth is more designed for a single live
>>>>> system
>>>>> like a desktop or a single server, whereas poudriere is what the
>>>>> freebsd
>>>>> package build clusters use and is more designed for that type of
>>>>> usage. Worth
>>>>> taking a look.
>>>>
>>>> These are package builders.  Technically preferable, given adequate
>>>> disk
>>>> space and memory, but not equivalent to portmaster.
>>>
>>> It's like saying git and svn are not equivalent to cvs.
>>
>> I have a hard time to see git in this line. Its the way you use it. Yes,
>> of course all three are code repositories. But one of them is a
>> distributed repository and the other two are not. The differences are
>> huge.
>> Of course it also depends on your usage. I personally (means "heavily
>> subjective) find git more than annoying. It lacks very important
>> features (user management), is hard to use in automatic environments and
>> make easy things (rename/delete branches) very hard. Other people really
>> like all of this. It depends.
>>
>> So maybe the accusers just use the wrong tool?
>
> The point is that you wouldn't start a new project with cvs.  You may or
> may not transfer an existing project from cvs, but you're letting cvs
> die by attribution.
>
> The same should be for portmaster.  Some users will never see the light.
>  Let them suffer by their own hand.  But for Pete's sake, don't
> recommend it to new users.  That's not doing them any kind of service.

I see recommendations for poudriere or synth, but not for portmaster. 
And i give them too.

But both are tools which are not feasible for every situation. I often 
have a hard time to get them their space they need to make things 
better. So it would be a good idea under which circumstances portmaster 
is a good choice and whenever it is not.

> Portmaster is not maintained.  Since you put your name on it, you've
> made not a single commit to the repository, much less a new release. Yet
> there are PRs on it.

No excuses here. You are right, but its another store. I approved a 
commit which than breaks portmaster even after very good testing. And 
that make me even more cautious. But also i'm not allowed to change the 
code or do changes by myself, so its no surprise its very hard and i 
considered to drop my maintainer line multiple times. Thats just beside 
that the code is not written in a way which supports testing. So there 
is a very big risk in every change. I started to rewrite it in an 
private repo, but since it works (i could close many PRs) it really is 
at the bottom of my list.

> Please, can we somehow discourage new people from starting on it?
> Anybody with a machine that doesn't have a resources to run poudriere or
> synth should not be building packages on that machine.

I provide a poudriere server for my customers. Its not to nice to use, 
but they can configure it like the need and without the pressure on 
their own server. Maybe we need something like this to make it easier to 
abandon portmaster.

Greetings,
Torsten



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb2515b7-4b06-d840-e370-a8a5416d8c47>