devel/google-perftools: Update to 2.6.3
ClosedPublic

Authored by yuri on Wed, Jan 3, 5:27 PM.

Details

Summary

Switched to github upstream.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
yuri created this revision.Wed, Jan 3, 5:27 PM
tcberner added inline comments.Wed, Jan 3, 6:31 PM
devel/google-perftools/Makefile
23 ↗(On Diff #37465)

^ don't add that comment

45 ↗(On Diff #37465)

^ seems like many unnecessary whitepace changes?

yuri marked 2 inline comments as done.Wed, Jan 3, 6:37 PM
yuri added inline comments.
devel/google-perftools/Makefile
45 ↗(On Diff #37465)

They add more alignment. Due to a bug, phabricator messes up tab alignment.
I added them on purpose.

yuri marked 2 inline comments as done.Wed, Jan 3, 7:40 PM
tcberner added inline comments.Wed, Jan 3, 7:53 PM
devel/google-perftools/Makefile
23 ↗(On Diff #37465)

Comment is still here :)

yuri updated this revision to Diff 37477.Wed, Jan 3, 7:58 PM
yuri marked an inline comment as done.

.

yuri added inline comments.Wed, Jan 3, 7:58 PM
devel/google-perftools/Makefile
23 ↗(On Diff #37465)

Forgot to update, sorry! :-)

mat added a comment.Thu, Jan 4, 8:20 AM

Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

mat added inline comments.Thu, Jan 4, 8:22 AM
devel/google-perftools/Makefile
45 ↗(On Diff #37465)

Phabricator displays tabs as 8 chars, this is a given, yes, but this still looks like unneeded whitespace change.

yuri marked 2 inline comments as done.Thu, Jan 4, 11:04 AM
In D13750#288014, @mat wrote:

Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

It's easier to try some other revisions when it is using GH_xxx tags. I did this many times. I submitted patches to this project, and have pending patches too.

mat added a comment.Thu, Jan 4, 12:24 PM
In D13750#288062, @yuri wrote:
In D13750#288014, @mat wrote:

Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

It's easier to try some other revisions when it is using GH_xxx tags. I did this many times. I submitted patches to this project, and have pending patches too.

The point is that people put work in making releases tarballs, that just work, do not need autoreconf, and what you do when you ignore those releases is say "let's ignore the work they did and do it again myself in here". Like I said, unless the release tarball is broken, use it. If you want to keep a "devel" version of the port on your side, it's fine, but do not force using git archives when it is not needed.

yuri added a comment.Thu, Jan 4, 12:28 PM
In D13750#288077, @mat wrote:
In D13750#288062, @yuri wrote:
In D13750#288014, @mat wrote:

Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

It's easier to try some other revisions when it is using GH_xxx tags. I did this many times. I submitted patches to this project, and have pending patches too.

The point is that people put work in making releases tarballs, that just work, do not need autoreconf, and what you do when you ignore those releases is say "let's ignore the work they did and do it again myself in here". Like I said, unless the release tarball is broken, use it. If you want to keep a "devel" version of the port on your side, it's fine, but do not force using git archives when it is not needed.

"people put work" - the work is mostly in making sure that the release is stable, tested, verified, went through the period of freeze. We got all this as it is now. The version is exactly the same. It uses autoreconf, but after autoreconf it is the same configure/makefiles.

adamw added a comment.Thu, Jan 4, 1:42 PM
In D13750#288087, @yuri wrote:
In D13750#288077, @mat wrote:

Like I said, unless the release tarball is broken, use it. If you want to keep a "devel" version of the port on your side, it's fine, but do not force using git archives when it is not needed.

"people put work" - the work is mostly in making sure that the release is stable, tested, verified, went through the period of freeze. We got all this as it is now. The version is exactly the same. It uses autoreconf, but after autoreconf it is the same configure/makefiles.

Yuri, @mat's comments weren't suggestions, they're policy. Once you're released from mentorship, you'll have more freedom to decide how to manage your own ports (though situations like this one won't change). While you're on mentorship, arguing against policy (especially when it comes directly from a member of portmgr) isn't appropriate.

Please, follow the instructions @mat is giving you. The point of mentorship is to learn how your mentors manage ports. You need to learn it their way first, and then you can develop your own way.

yuri updated this revision to Diff 37524.Thu, Jan 4, 7:06 PM

Update to tarballs.

Could you verify whether the dependencies still are happy?

devel/google-perftools/Makefile
11 ↗(On Diff #37524)

^@FreeBSD.org?

yuri added a comment.Mon, Jan 8, 8:42 PM

Could you verify whether the dependencies still are happy?

Nobody depends on it in the default configuration.
I verified, Tor likes it when the corresponding option is selected.
Also perftool's interface never changes.

yuri marked an inline comment as done.Mon, Jan 8, 8:44 PM
tcberner accepted this revision.Mon, Jan 8, 8:50 PM

Let's hope you're right ;)

This revision is now accepted and ready to land.Mon, Jan 8, 8:50 PM
This revision was automatically updated to reflect the committed changes.