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
F105112837: D13750.diff
Thu, Dec 12, 12:35 PM
Unknown Object (File)
Tue, Dec 10, 11:05 AM
Unknown Object (File)
Oct 18 2024, 9:20 PM
Unknown Object (File)
Oct 18 2024, 8:41 PM
Unknown Object (File)
Oct 18 2024, 5:06 PM
Unknown Object (File)
Oct 18 2024, 3:13 AM
Unknown Object (File)
Oct 5 2024, 7:49 PM
Unknown Object (File)
Oct 3 2024, 2:34 PM
Subscribers

Details

Summary

Switched to github upstream.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 14090
Build 14270: arc lint + arc unit

Event Timeline

devel/google-perftools/Makefile
23

^ don't add that comment

45

^ 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

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

Comment is still here :)

yuri marked an inline comment as done.

.

devel/google-perftools/Makefile
23

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

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
9

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