Solved Questions on portsnap

P

Peacekeeper2000

While I am using portsnap now for years, I was looking for a supression of the output that portsnap produce. So I was looking for something like -q (quiet) . Instead I found a -I switch which produces only the index. I wonder why would I use that switch/option ? What is the benefit ?

During portsnap update I don't care, what packages/ports are updated as I do have an alias
Bash: 
chkpkg='pkg version -vl "<"'
which I run afterwards to understand if I need to start portmaster. So is there a quick way to supress the output of portsnap lines with all the package names ?
 
Just verified - my fault: I thought that everything the portsnap script will do , will be nulled.
But why would I use the index-only switch ?
 
Peacekeeper2000 said:
I thought that everything the portsnap script will do , will be nulled.
Click to expand...
Of course not. The only thing you would be doing is redirect STDOUT and/or STDERR.

Standard streams - Wikipedia

en.wikipedia.org en.wikipedia.org

Peacekeeper2000 said:
But why would I use the index-only switch ?
Click to expand...
Many tools can operate on the INDEX alone.

Code: 
     -I [index, --index [index]]
                 Use index file for determining if a package is out of date.
                 If no index file name is specified, uses the default index
                 file.  This is the default, if the index file exists.
pkg-version(8)
 
Hmm, ok - I could do a check after the index is build. If the check shows no update on the packages I use, I am a bit faster. I wonder what happen next time when a package needs an update: I will run portsnap update a second time. And will it then update also the former missed packages ? To be honest, I still don't get the benefits. The fetch is anyhow done - so no download time saved. But the portstree and the default index is out of sync. Hmm, strange - I would love more the -q(uiet) option :D
 
SirDice said:
You might want to move away from portsnap(8) anyway. It's going to be removed some time in the future.
Click to expand...
It seems the forces to keep "old stuff" are strong, so no idea when that will actually happen, although it was already proven there's neither a benefit in disks space nor network traffic compared to directly using git...

Peacekeeper2000 said:
Uhh - what will be the replacement ?
Click to expand...
In general, right now: git or gitup, both in ports... if you mean in base, I don't think there's a concrete plan yet. I think, maybe including gitup in base could be an option.

edit: gitup is a simple tool just using the git repo for download, so essentially and very simplified: portsnap without the need for extra server-side infrastructure. It's much simpler to use than "real" git, so might be a good option for anyone who just wants to fetch ports without doing any own development...
 
You know: "once you get old with your horse, there is no need for a new one as long as th old is doing the work" :D which is similar to "never change a running system"

But I would understand to simplify things like the ports-tree using git or git clone. I also use it for my private builds. On the other side it is a new dependency for FreeBSD , while - as long as I know - the ports tree on an install server is using only simple basic tools ( like tar etc. ) Maybe the older people will get a portsnap that hides the git commands :D - just kidding

But for now, I am good with portsnap / portmaster etc. - works :D
 
Peacekeeper2000 the issue with portsnap is, it needs extra server side infrastructure that must be maintained (there's a reason you didn't get portsnap updates for quite a while after ports moved from subversion to git). Back with cvs and probably also svn, this could be justified because portsnap was simpler and more efficient than using the vcs tool directly. This definitely is no longer the case with git (and with gitup, a super simple "fetch-only" tool exists as well, using the hosted repository directly).

One thing that can't be done is to include the original git in base, for licensing reasons. Indeed, it would be nice to have some tool in base that allows to easily update your local ports branch. That's probably one of the reasons portsnap is still there in 13...
 
Yeah & Thanks - I just reviewed the handbook again. There is git already mentioned for installation and updates - seems I have to re-read the handbook more often :D
 
zirias@ said:
Peacekeeper2000 the issue with portsnap is, it needs extra server side infrastructure that must be maintained (there's a reason you didn't get portsnap updates for quite a while after ports moved from subversion to git). Back with cvs and probably also svn, this could be justified because portsnap was simpler and more efficient than using the vcs tool directly. This definitely is no longer the case with git (and with gitup, a super simple "fetch-only" tool exists as well, using the hosted repository directly).

One thing that can't be done is to include the original git in base, for licensing reasons. Indeed, it would be nice to have some tool in base that allows to easily update your local ports branch. That's probably one of the reasons portsnap is still there in 13...
Click to expand...
Ah, thanks for the info. Then of course git is the better choice with no server-side infrastructure required. And as I have installed anyhow git, it is a possibility to e.g. get rid of another package (portmaster) on my boxes in the future.
 
Peacekeeper2000 said:
Ah, thanks for the info. Then of course git is the better choice with no server-side infrastructure required.
Click to expand...
Well, no additional ... of course, a hosted git service is needed, but that's already needed for development anyways ;)

Peacekeeper2000 said:
And as I have installed anyhow git, it is a possibility to e.g. get rid of another package (portmaster) on my boxes in the future.
Click to expand...
Wait, this is a different aspect than how you fetch your ports. Although I'd always recommend poudriere (it's just much safer to build in clean jails, even complex upgrades are pretty simple that way, and with poudriere-devel, you have a safe way to mix in some binary packages) – portmaster is still "okayish" if you insist to build directly on the machine. At least, it's much better than trying to manage ports completely manually, using nothing but make ;)
 
You must log in or register to reply here.
Back
Top