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.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
