Page MenuHomeFreeBSD

devel/google-perftools: Update to 2.6.3
ClosedPublic

Authored by yuri on Jan 3 2018, 5:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Mar 10, 12:06 AM
Unknown Object (File)
Sun, Mar 10, 12:06 AM
Unknown Object (File)
Sun, Mar 10, 12:06 AM
Unknown Object (File)
Sun, Mar 10, 12:06 AM
Unknown Object (File)
Sun, Mar 10, 12:06 AM
Unknown Object (File)
Sun, Mar 10, 12:06 AM
Unknown Object (File)
Sun, Mar 10, 12:06 AM
Unknown Object (File)
Sat, Mar 9, 11:54 PM
Subscribers

Details

Summary

Switched to github upstream.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

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.Jan 3 2018, 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.Jan 3 2018, 7:40 PM
devel/google-perftools/Makefile
23 ↗(On Diff #37465)

Comment is still here :)

yuri marked an inline comment as done.

.

devel/google-perftools/Makefile
23 ↗(On Diff #37465)

Forgot to update, sorry! :-)

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.

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.Jan 4 2018, 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.

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.

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.

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.

Could you verify whether the dependencies still are happy?

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

^@FreeBSD.org?

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.Jan 8 2018, 8:44 PM

Let's hope you're right ;)

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