Do not use ports-mgmt/portmaster and other tools who build in the main system

[Jose]

There is no binary answer to this. Trying to force "Is this right?" patterns is prompting for reactance. You will be shown that there is a "depends on".

Note the winky emoji in his post.

A missing item among others in the poll is: "I do not care."

Why read the thread and post in it if you don't care?

It would be nice to know how to not do this. Packages seem to default to quarterly (Which sometimes backports security updates?) and ports using portsnap (as the handbook suggests) defaults to... something very recent?

I found Vigole's recent post on the subject illuminating. Here's the mailing list message announcing the quarterly branch:

[FreeBSD-Ports-Announce] [ANNOUNCE] ports 2014Q2 branched

 

[olli@]

It would be nice to know how to not do this. Packages seem to default to quarterly (Which sometimes backports security updates?) and ports using portsnap (as the handbook suggests) defaults to... something very recent?

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 ^(*). This is the same as when using net/svnup with the “ports” keyword which checks out ports/head.

^(*) Well, almost. The portsnap data is generated at certain intervals, so it may lag slightly behind the Subversion repository. This doesn’t matter for most practical purposes, though.

 

[msplsh]

Portsnap (which is apparently going to be declared obsolete when the switch from Subversion to Git happens) does not support the notion of branches.

I put a little more effort into this and found -b

So, maybe the handbook should instead of "here's one way, here's another" instead be like "here's how to get latest (portsnap), here's how to get quarterly (svnup)"

pkg install svnup
cd /usr/ports
svnup ports -b 2020Q3 -h svn.freebsd.org

Does that look right?

 

[olli@]

pkg install svnup
cd /usr/ports
svnup ports -b 2020Q3 -h svn.freebsd.org

Does that look right?

Almost. I think you need -b ports/branches/220Q4. You can look up the structure at svnweb.freebsd.org.

 

[PacketMan]

Take a look at the source code for synth -- I've seldom seen such clean and beautiful code. Even if developers do prefer to build with the poudriere script (and use jails instead of null mounts to allow building malicious/bad-actor ports) every programmer could benefit from learning a little bit from synth's Ada code. It is really sweet. And I have to add that I've seldom seen any package receive such good support as synth does here. Mention any problem with synth and the author will be show up as if by magic to help...

(Synth is the most straight-forward replacement for portmaster:

synth configure
synth upgrade-system
synth install <port>

ports-mgmt/synth is awesome, its all I use. And its creator John Marino is a master of code it seems. If it were to become unmaintained I would make figure out how to use ports-mgmt/poudriere plain and simple.

 

[chrcol]

olli@ I have already removed portsnap of my base system and have a cron'd script to update my quartery branch nightly, it also auto detects when the quarter changes.

I hope a new tool is created when they move to git, as git is so less user friendly and slower vs svn.

 

[Oclair]

I wonder if actually all this FUD pointed towards portmaster and portsnap because we're going into a Microsoft owned GIT and away from SVN?

 

[msplsh]

Oh geez, please delete this. Microsoft does not own git and the reason why these have problems is presumably neglect and disinterest.

 

[Jose]

I wonder if actually all this FUD pointed towards portmaster and portsnap because we're going into a Microsoft owned GIT and away from SVN?

That tinfoil hat doesn't go with the rest of your outfit.

 

[Jose]

From the BSD link roundup post from today:

So yes it is true that we do not yet have FLAVORs nor subpackages but there is some ongoing work to provides those features in the ports tree (actually in final review right now). That work is pretty hard as it breaks the design of some tools that are heavily used by our users like portmaster and portupgrade and which are barely maintained; meaning we need to find an upgrade path which will not break those. We try to always have an upgrade path for users and try to avoid hard breakage. Keep in mind that we do not release a package set, but the ports tree is a rolling release not tied to a FreeBSD release.

 

[Oclair]

I remember when FreeBSD 5 was released and when I upgraded it broke all of my 4.11 boxes (yes boxes)

 

[Oclair]

Oh geez, please delete this. Microsoft does not own git and the reason why these have problems is presumably neglect and disinterest.

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.

 

[xtaz]

I remember when FreeBSD 5 was released and when I upgraded it broke all of my 4.11 boxes (yes boxes)

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.

Since then the changes between major versions have been much more incremental as there's a new major release every year or so.

 

[Lamia]

I put a little more effort into this and found -b

So, maybe the handbook should instead of "here's one way, here's another" instead be like "here's how to get latest (portsnap), here's how to get quarterly (svnup)"

pkg install svnup
cd /usr/ports
svnup ports -b 2020Q3 -h svn.freebsd.org

Does that look right?

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.

 

[Snurg]

I have read the whole thread, but didn't find an answer yet for my problem.

SirDice teached me that I can use poudriere to build packages with my own patches, in a way that it keeps/merges these patches through updates.
As far as I understand, the disadvantage of using poudriere is that poudriere cannot just build on demand what you need.
You have either to build ALL gazillions of packages, or to list a fixed set of packages to build.

This is not nice if you want to build only what you actually need.

Could I use synth together with the trick @Mjölnir revealed in this post, to build and install what I need just when I need it, together with the patches?

Aim would be to integrate inofficial patches, hacks and things like stuff being discussed on phabricator, but not yet added in the <current> repo.

 

[zirias@]

As far as I understand, the disadvantage of using poudriere is that poudriere cannot just build on demand what you need.
You have either to build ALL gazillions of packages, or to list a fixed set of packages to build.

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.

 

[Mjölnir]

Snurg, I guess you mean that you want to be able to bypass re-building dependent ports? That's bogus - think about it... OTOH, I understand that if you just change an option of a port, you don't want to rebuild all dependents when you know they'll not be affected by that change. But that's not reflected in the dependency rules in the Makefiles - and it would be very labourous to do so. Maybe by introducing tag files for each port-option tuple; but that would explode the #rules exponentially...

 

[Deleted member 30996]

Debunked.

portmaster -F x11/kde5 (recursively fetch all distfiles needed to build kde5)
The result is that after more than one hour of uselessly processing the dependency graph, this self-called master still fetches nothing.

This will do the job, pull in a list of all dependencies it deems necessary for the build, then present them to you for authorization to proceed, or options should you not want to install everything it shows. I go with it unless it's something like IPV6 I've disabled or something I know to watch for to disable during the time it's presented to me.

root@jigoku:/ # portmaster x11/kde5

Don't add a flag to the command and blame the problem encountered by doing so on the program when it doesn't do what you thought it would. That's what Linux people do when they say FreeBSD no worky right for penguin and blame FreeBSD for their own Tuxix Shock Syndrome.

 

[Mjölnir]

Don't add a flag to the command and blame the problem encountered by doing so on the program when it doesn't do what you thought it would. [...]

Please stay factual. From the portmaster(8) manpage:

     [--force-config|-G] [-aftv] -F
     fetch distfiles only

That's exactly what I wanted it to do & I communicated that accurately in the post you referenced. Please check & verify that this tool applies an O(n^2) (or worse) algorithm where others (i.e. any make(1)-like build tool) has linear runtime: compare

• 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.)

Conclusion: there's nothing to be debunked.

 

[Deleted member 30996]

What you based your whole theorem of program failure on in using:
[cmd]portmaster -F x11/kde5[/cmd]

Was refuted with years of test proven fact and a 100% success rate using the same command for everything built without the -F fag:
[cmd]portmaster x11/kde5[/cmd]

The only difference being I don't use KDE and for me it's:
portmaster x11-wm/fluxbox

Free your mind and fluxbox will follow.

 

[zirias@]

TBH, I don't understand the manpage here regarding the exact purpose of this mode, but it clearly indicates you can't give a specific port with -F (it is not one of the "common flags").

Still I think portmaster is a tool from the past anyways and will (slowly) vanish.

 

[Mjölnir]

What you based your whole theorem of program failure on in using:
portmaster -F x11/kde5
Was refuted with years of test proven fact and a 100% success rate using the same command for everything built without the -F fag:
portmaster x11/kde5

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.

Free your mind and fluxbox will follow.

I do like this signature.

 

[Mjölnir]

TBH, I don't understand the manpage here regarding the exact purpose of this mode, but it clearly indicates you can't give a specific port with -F (it is not one of the "common flags").

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).

Still I think portmaster is a tool from the past anyways and will (slowly) vanish.

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...

 

[zirias@]

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).

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…

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...

Maybe there's a usecase. Not for me, though – if you use ZFS anyways, poudriere is simpler AND more robust.

 

[Deleted member 30996]

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.

In the area of unnecessary fiddling and fumbling around in wasting time to get the job done it's probably exactly what you wanted in maintaining your level of inexperience in the use of it. A point I tried to talk around but not successful at getting across in my Circumlocution.

I like to avoid that as much as possible. Therefore, use what I know from experience will start the job and finish it in the most efficient manner possible with no wasting of time in my efforts.