The ports collection has some serious issues

[Vlad K.]

On 2016-12-08 06:16, Daniil Berendeev wrote:
> * Why pkg is still nice?
> It is able to update packages with broken ABI, it's fast and easy to
> use. Some packages/ports don't have options and can be used via pkg by 
> a
> ports user.

Yes, and I'll echo what Matt said previously, and suggest Poudriere. 
I've been using it exclusively for over a year and I've observed it 
cleanly rebuild ports others have had hell of a time with, with 
portmaster, eg. Perl upgrades.

Working with pkgs you pre-built yourself is the most atomic and flexible 
way to have and use the ports ecosystem.


> 2) pkg and ports are not in sync.
> pkg appeals to build ports that are from 2xxxQx branches. The promoted
> tool for syncing ports (portsnap) always fetches from head. And there 
> is
> no way to choose. That gives us the next problem:

There is way to choose. You can change your pkg repo to "latest" via 
/etc/pkg/FreeBSD.conf, or even better override it into 
/usr/local/etc/pkg/repos/FreeBSD.conf (will need to create last two 
dirs). See pkg.conf(5) for more info.

And that's if you use the official FreeBSD pkg builds. Another good 
reason to use Poudriere and build pkgs yourself.


> 6) broken ports are pushed to head
> Why do we have such a situation, when head contains a handful of broken
> ports? Why commit a port that won't build? It's sick.

Well, that's normal? A little fact often neglected is that the HEAD is 
basically what 
ultra-unstable-we-just-committed-here-use-at-your-own-risk repos of some 
Linux distros are.

I mean, they are the FIRST landing point of a change. And the only QA we 
ask for that change is a confirmation that poudriere and portlint have 
been run, the rest is at liberty of committers how far they'll go with 
own testing before they commit. For many, only builds against -CURRENT 
or latest -RELEASE are done because it's very time consuming to test 
against all supported FreeBSD versions, and not just versions but 
various permutations like different pythons etc... When it comes to some 
defaults like OpenSSL (or any kind of dependency on it), all of those 
tests are required.

The problem is, FreeBSD doesn't have a STABLE repo that would receive 
gradual updates from HEAD as they prove themselves stable. QUARTERLY != 
STABLE, it's just a snapshot of whatever state HEAD is in, with a loose 
promise the ports in it will receive "security and bugfixes only" but 
that's a separate set of issues.

There are some solutions and we don't have to NIH or reinvent the wheel. 
Just looking at what other open source projects do with, say, GitHub and 
continuous integration testing, every pull request gets an automated 
test. Why don't we do that? Is it difficult to implement it?

I am also convinced that such testing can be automated and a true 
"STABLE" repo can be made instead of manual QUARTERLY that breaks 
promises.


> 8) ports with vulnerabilities.
> They exist in the tree and on build attempt they shout that they won't
> build without DISABLE_VULNERABILITIES=yes. The catch is that there is
> always a bunch of ports with vulnerabilities. So if you are doing a

That's just a nature of it, and the consequence of VuXML being a 
separate port that gets often updated first, as it's better to announce 
the vuln before it was fixed. And fixing is bound to maintainer 
timeouts, poor issue tracking via Bugzilla, etc...



> I hope that my mail will produce a productive discussion that will lead
> to some good decisions for fixing these problems.

Probably not. I've already posted about issues with head/quarterly, 
hoping for a discussion, never happened. Others have complained about 
the same problem, but no constructive discussion ensued. Is my 
frustration coming through, yet? :)





-- 

Vlad K.