Note the winky emoji in his post.
Why read the thread and post in it if you don't care?
I found Vigole's recent post on the subject illuminating. Here's the mailing list message announcing the quarterly branch:
Note the winky emoji in his post.
Why read the thread and post in it if you don't care?
I found Vigole's recent post on the subject illuminating. Here's the mailing list message announcing the quarterly branch:
Portsnap (which is apparently going to be declared obsolete when the switch from Subversion to Git happens) does not support the notion of branches. It always gives you “head”, i.e. the most current state of the ports repository [sup](*)[/sup]. This is the same as when using net/svnup with the “ports” keyword which checks out
ports/head.
pkg install svnup
cd /usr/ports
svnup ports -b 2020Q3 -h svn.freebsd.org
Almost. I think you need
-b ports/branches/220Q4. You can look up the structure at svnweb.freebsd.org.That tinfoil hat doesn't go with the rest of your outfit.
Maybe you might mean assume? as "assumption" suggests there is little evidence supporting your guess. Think carefully before using them interchangeably or you may lose some meaning.
To be fair, back then the development/release model was massively different to how it is today. 5 was in development for several years and had huge very breaking changes to 4. 5.0-RELEASE itself was full of bugs as well. It's the reason DragonFly BSD forked from FreeBSD at that point as they didn't like the direction the 5 code had taken over the 4 code.
Yes, it does. We are sometimes unlucky with building all ports needed by our boxes. You might notice it as you switch among 2020Q2, 2020Q3 and even 2020Q4. 2020Q1 works well most of the time. The Q4 showed non-existent ports for all x11-related ports just last week.
Huh?
poudriere bulk accepts a list of ports on the commandline, being able to pass this list from a file is just convenience. It will only build what you give it and what is necessary as a dependency. If dependencies were previously built in the required version, it will of course NOT rebuild them.
Please stay factual. From the portmaster(8) manpage:
[--force-config|-G] [-aftv] -F
fetch distfiles only portmaster -F x11/kde5 (will process the dep graph for veeeeery looooong time...) versus make -C /usr/ports/x11/kde5 fetch-recursive (starts to download after some sec. or min.)[cmd]portmaster -F x11/kde5[/cmd][cmd]portmaster x11/kde5[/cmd] portmaster x11-wm/fluxbox
Please thoroughly read what I wrote:
portmaster -F is documented in it's manpage to "fetch distfiles only". Thus what I wrote is not refuted, but simply results in so-called portmaster pondering about which files to download for over an hour on a decent modern laptop... whereas the functionally equivalent make(1) command as given above, needs a small fraction of time to decide what to do & starts downloading quickly.I do like this signature.
Then let it run until it has finished calculating the list of files & starts to download =>
-F can handle a target (port to act on).No, it is beeing rewritten -- & hopefully some of it's algorithms redesigned/replaced with appropriate ones, as well -- in Lua for a few years now...
Well IF this is true (I can't tell cause I don't use portmaster and don't want to install it) then the manpage is wrong. According to the manpage, it isn't possible, which of course leaves me wondering what this option is meant for…
Maybe there's a usecase. Not for me, though – if you use ZFS anyways, poudriere is simpler AND more robust.