Solved Ports tree is already up to date

[Aknot]

I'm not sure I understand what's happening here.
Is there anywhere I can read about this?

Thanks,

# portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
Ports tree is already up to date.

 

[zirias@]

Portsnap should still be supported if I didn't miss anything – but it will always lag behind a bit, the snapshots are only created every now and then.

For accessing git directly, see for example

Solved - starting port updates

Hello. The last time the ports were updated a week ago. Now I start updating ports and receive messages that the ports have not changed, there are no updates. # portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... none found. Fetching snapshot tag from portsnap.FreeBSD.org... done...

forums.freebsd.org

 

[Mjölnir]

I'm not sure I understand what's happening here. Is there anywhere I can read about this?

Webster's Dictionary? What exactly is unclear here?

# portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
Ports tree is already up to date.

 

[olli@]

I'm not sure I understand what's happening here.
Is there anywhere I can read about this?

Thanks,

# portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
Ports tree is already up to date.

Portsnap is currently “frozen” during the migration from Subversion to Git. That’s why you don’t get any updates at the moment.
It will resume when the dust has settled. Just a little patience.

Irrespective of the Subversion/Git switch, Portsnap will continue to be supported at least for the lifetime of the stable/13 branch.
Alternatively, you can use gitup (net/gitup) to update your ports tree using the new Git infrastructure, if you want. It’s easy to use (very similiar to the existing svnup tool).

 

[olli@]

Portsnap should still be supported if I didn't miss anything – but it will always lag behind a bit, the snapshots are only created every now and then.

Portsnap is usually only a few hours (at most) behind the repository. This shouldn’t be an issue for most use cases.
 
Note that portsnap doesn’t distribute monolithic snapshots (despite its name). A full snapshot is created on the server only every few days (or maybe even once per day, I’m not sure), but incremental updates are created every hour.

 

[Aknot]

Thank you all ?

I did find a post by SirDice after posting this, and when I read it, I remember this was going to happen eventually (now).

If there is support for portsnap throughout stable/12 branch - I think we will wait to move to gitup (net/gitup) until we move to stable/13 branch.

 

[zirias@]

Portsnap is usually only a few hours (at most) behind the repository. This shouldn’t be an issue for most use cases.

That's more often than i thought, indeed. Still it seems planned to deprecate it (and there are a few good arguments why it doesn't really add value in the announcement about that). Having now learned about broken INDEX creation and not wanting to touch that as long as portsnap is still supported – well, doesn't affect me, but it sounds even more like a good idea to get rid of it eventually.

Note that portsnap doesn’t distribute monolithic snapshots (despite its name)

I didn't expect it to do that, that would be very inefficient

 

[olli@]

That's more often than i thought, indeed. Still it seems planned to deprecate it (and there are a few good arguments why it doesn't really add value in the announcement about that). Having now learned about broken INDEX creation and not wanting to touch that as long as portsnap is still supported – well, doesn't affect me, but it sounds even more like a good idea to get rid of it eventually.

Well, the main advantage of portsnap is that it’s extremely simple to use (admittedly, gitup is almost as simple to use), it is basically fool-proof and provides special precautions so you can safely use it from cron. And it has a huge userbase because it was the official standard way to update your ports tree (for non-developers) for almost two decades – I guess this is why FreeBSD won’t turn it off soon, but declares a rather long depreciation phase. AFAIK it will continue to be supported at least for the lifetime of the stable/13 branch.
 
As far as the INDEX file is concerned – I don’t really know how relevant this is. The ports framework and package infrastructure (including poudriere and other 3rd-party tools) do not use the INDEX file. I guess it exists only for historic reasons; you can safely ignore or even delete it. If you need it for some reason and you care about the deviations caused by ports that provide “flavours”, you can easily generate a local copy yourself with make index.

Edit: I think the make search feature of the ports collection might actually use the INDEX file. But for this feature, the flavours issue should be harmless.

 

[zirias@]

Well, the main advantage of portsnap is that it’s extremely simple to use (admittedly, gitup is almost as simple to use), it is basically fool-proof and provides special precautions so you can safely use it from cron. And it has a huge userbase because it was the official standard way to update your ports tree (for non-developers) for almost two decades – I guess this is why FreeBSD won’t turn it off soon, but declares a rather long depreciation phase. AFAIK it will continue to be supported at least for the lifetime of the stable/13 branch.

This should be mandatory now, as it wasn't removed before creating that branch, as initially planned. FreeBSD is very slow with these things (which is often good for end users of course).

 
As far as the INDEX file is concerned – I don’t really know how relevant this is. The ports framework and package infrastructure (including poudriere and other 3rd-party tools) do not use the INDEX file. I guess it exists only for historic reasons; you can safely ignore or even delete it. If you need it for some reason and you care about the deviations caused by ports that provide “flavours”, you can easily generate a local copy yourself with make index.

The problem goes deeper, as the creation is broken with flavors, so creating it locally won't help.

One tool using the index is pkg-version with -I flag, and from some postings here on the forums, it seems quite a few people use it. It will give occasionally wrong information though…