The future of portmaster
Jeffrey Bouquet
jeffreybouquet at yahoo.com
Tue May 30 15:57:29 UTC 2017
tl/dr at bottom, repeated here, flowchart please
--------------------------------------------
On Tue, 5/30/17, Adam Weinberger <adamw at adamw.org> wrote:
Subject: Re: The future of portmaster
To: mexas at bris.ac.uk
Cc: rollingbits at gmail.com, freebsd-ports at freebsd.org
Date: Tuesday, May 30, 2017, 7:30 AM
> On 30 May, 2017, at 8:15,
Anton Shterenlikht <mexas at bris.ac.uk>
wrote:
>
>> From
adamw at adamw.org
Tue May 30 15:03:31 2017
>>
>> The ports tree continues to evolve.
Major new features are planned and in the process of being
implemented. These changes will break all the port-building
tools.
>
> oy vei
>
>> poudriere and
synth are actively developed, so they will quickly support
the new changes. portmaster and portupgrade are no longer
being actively developed, so it is anticipated that they
will stop working until somebody fixes them (if at all).
>
> I last used
poudriere a couple years back.
> It is
much more involved than portmaster
>
(obviously, these 2 tools are not doing the same job)
There's definitely more
work up-front to set up poudriere. You get the effort back,
though, in long-term viability and not having to chase
problems up and down the ports tree.
>> So no, portmaster isn't going
away. But, there's no guarantee that it will keep
working. We strongly, strongly advise everyone to use
poudriere or synth to build their ports, and then plain old
"pkg upgrade" to handle updates.
>
> because my
experience of poudriere was mixed,
> I
haven't used it at all on amd64.
>
pkg is great. And when occasionally I need
> non-default options I use portmaster.
>
>>
>> The vast majority of problems reported
on this mailing list exist only in portmaster/portupgrade,
because they do not do clean builds. At this point,
portmaster should only be used by people with enough ports
development experience to understand and mitigate conflicts
and various build errors.
>
> I agree that a dirty environement is
mostly
> the source of bad portmaster
builds.
>
> However,
to create the whole poudriere enviroment
> to build a port a week, or maybe a month,
seems
> like an overkill.
>
> Yes, I know,
it's a volunteer project, things
>
evolve, unless somebody steps in...
>
> If my recollection of poudriere is
correct,
> I'll need a separate ports
tree?
> And if I only need to build a
single port
> with custom settings,
I'll have to start
> every time from
scratch?
> And if I want to use this
single port with
> default settings with
my other ports, I need
> to make sure the
2 port trees are in sync.
>
> Sorry if I don't do poudeire justice,
it's been a while...
You don't need separate port trees. The
idea is to use poudriere to build ALL your ports. Just make
a list of the ports you want, pass it to poudriere, and it
will keep everything up-to-date, rebuild things when they
need to be rebuilt, and give you a pkg repository so you can
just run "pkg install foo" or "pkg
upgrade" to keep your system running.
Even if you do use poudriere
to build only a few ports, it's pretty easy. Give your
own generated packages a higher priority in
/usr/local/etc/pkg/repos/ and you can transparently layer
your pkg repo above the upstream repo.
So no, you don't need separate ports trees.
poudriere is happiest though when you let it manage its own
ports tree, so I prefer to just symlink /usr/ports to it,
but you can very easily use a pre-existing ports tree with
poudriere.
# Adam
--
Adam Weinberger
adamw at adamw.org
https://www.adamw.org
_______________________________________________
freebsd-ports at freebsd.org
mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
Sorry for the yahoo webclient not quoting the above.
If applicable.
Leaving aside my wishes for the /usr/ports/MOVED/portmanager *also* eventually back
upto speed with portmaster, even as shareware, this poudriere and even synth I think
could benefit from a flowchart... right side differing scenarios what one's goals are
left and work backwards thru all the things can go wrong, dotted boxes 'errors' and
arrows to the solution(s) paths, [ and a third part of this flowchart I just thought of
...] and on the left simple boxes, like one server one lan, two servers two lan,
one server a VPN three hundred downstream 'subscriber' clients for the built ports,
and any other things, more visually explained than a much longer wiki reading.
................................
tl/dr flowchart please
More information about the freebsd-ports
mailing list