This repository has been archived by the owner. It is now read-only.

Changed outputdir for locate databases #14945

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
@halloleo
Contributor

halloleo commented Sep 14, 2012

(g)updatedb and (g)locate use databases which are
system-generated. Under hombrew they were generated in the findutils
tree, on other unix systems they live normally in /var/locate or
/var/cache under root. I set the default to var/locate under
HOMEBREW_PREFIX.

halloleo
Changed outputdir for locate databases
`(g)updatedb` and `(g)locate` use databases which are
system-generated. Under hombrew they were generated in the `findutils`
tree, on other unix systems they live normally in `/var/locate` or
`/var/cache` under root. I set the default to `var/locate` under
`HOMEBREW_PREFIX`.
@halloleo

This comment has been minimized.

Show comment Hide comment
@halloleo

halloleo Sep 14, 2012

Contributor

This is a newly created pull request replicating an old one which I deleted.

I wanted to squash my two small commits. However due to homebrew updates in the meanwhile there where many external commits interspersed. Therefore it was the easiest for me to delete my old homebrew fork and create a new one.

So here the squashed commit as a new pull request.

Contributor

halloleo commented Sep 14, 2012

This is a newly created pull request replicating an old one which I deleted.

I wanted to squash my two small commits. However due to homebrew updates in the meanwhile there where many external commits interspersed. Therefore it was the easiest for me to delete my old homebrew fork and create a new one.

So here the squashed commit as a new pull request.

@mxcl

This comment has been minimized.

Show comment Hide comment
@mxcl

mxcl Sep 26, 2012

Member

Should it be set to just #{var}? Since the default is PREFIX/var.

Member

mxcl commented Sep 26, 2012

Should it be set to just #{var}? Since the default is PREFIX/var.

@halloleo

This comment has been minimized.

Show comment Hide comment
@halloleo

halloleo Sep 27, 2012

Contributor

Well, different unix implementations seem to put the locate database in different spots. #{var} is one, #{var}/lib and #{var}/locate are others. I prefer the latter.

On 27/09/2012, at 9:53 AM, Max Howell notifications@github.com wrote:

Should it be set to just #{var}? Since the default is PREFIX/var.


Reply to this email directly or view it on GitHub.

Contributor

halloleo commented Sep 27, 2012

Well, different unix implementations seem to put the locate database in different spots. #{var} is one, #{var}/lib and #{var}/locate are others. I prefer the latter.

On 27/09/2012, at 9:53 AM, Max Howell notifications@github.com wrote:

Should it be set to just #{var}? Since the default is PREFIX/var.


Reply to this email directly or view it on GitHub.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Dec 3, 2012

Contributor

I think it is good to have the database not in the Cellar but in "#{var}/locate" as this (modified) pull requests suggests.

Right now (without this PR), the database is at $(brew --prefix)/bin/gupdatedb: line 278: $(brew --prefix)/Cellar/findutils/4.4.2/var/locatedb.n: No such file or directory and won't survive version updates.

Contributor

samueljohn commented Dec 3, 2012

I think it is good to have the database not in the Cellar but in "#{var}/locate" as this (modified) pull requests suggests.

Right now (without this PR), the database is at $(brew --prefix)/bin/gupdatedb: line 278: $(brew --prefix)/Cellar/findutils/4.4.2/var/locatedb.n: No such file or directory and won't survive version updates.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Dec 3, 2012

Contributor

So in other words: Why not pull this now?

Contributor

samueljohn commented Dec 3, 2012

So in other words: Why not pull this now?

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Dec 3, 2012

Contributor

Ok; GitHub is saying "This pull request cannot be automatically merged."; can we get a rebase?

Contributor

adamv commented Dec 3, 2012

Ok; GitHub is saying "This pull request cannot be automatically merged."; can we get a rebase?

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Dec 3, 2012

Contributor

@halloleo your turn :-)

Contributor

samueljohn commented Dec 3, 2012

@halloleo your turn :-)

@halloleo

This comment has been minimized.

Show comment Hide comment
@halloleo

halloleo Dec 3, 2012

Contributor

Ok, I agree to have the database in "#{var}/locate", but I'm not a git(hub) expert, what do I do to merge this request? How do I "rebase" it?

On 04/12/2012, at 5:08 AM, Samuel John notifications@github.com wrote:

@halloleo your turn :-)


Reply to this email directly or view it on GitHub.

Contributor

halloleo commented Dec 3, 2012

Ok, I agree to have the database in "#{var}/locate", but I'm not a git(hub) expert, what do I do to merge this request? How do I "rebase" it?

On 04/12/2012, at 5:08 AM, Samuel John notifications@github.com wrote:

@halloleo your turn :-)


Reply to this email directly or view it on GitHub.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Dec 3, 2012

Contributor

You are working in your "master" branch, right? Normally we use a separate branch for modifications, but if this is the only thing you are working on, you can cd $(brew --prefix) and git pull --rebase

Contributor

samueljohn commented Dec 3, 2012

You are working in your "master" branch, right? Normally we use a separate branch for modifications, but if this is the only thing you are working on, you can cd $(brew --prefix) and git pull --rebase

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Dec 3, 2012

Contributor

Probably git pull upstream --rebase (not sure how the default naming of remotes is. See brew remote -v).
After that git push --force origin (origin is my guess here, again).

Contributor

samueljohn commented Dec 3, 2012

Probably git pull upstream --rebase (not sure how the default naming of remotes is. See brew remote -v).
After that git push --force origin (origin is my guess here, again).

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Dec 4, 2012

Member

Just pushed my own version.

Member

MikeMcQuaid commented Dec 4, 2012

Just pushed my own version.

@samueljohn

This comment has been minimized.

Show comment Hide comment
@samueljohn

samueljohn Dec 4, 2012

Contributor

Nice, thanks @MikeMcQuaid. And thank you @halloleo for the initial idea!

Contributor

samueljohn commented Dec 4, 2012

Nice, thanks @MikeMcQuaid. And thank you @halloleo for the initial idea!

@halloleo

This comment has been minimized.

Show comment Hide comment
@halloleo

halloleo Dec 4, 2012

Contributor

Thanks Mike, for taking care of the git pushing.

On 04/12/2012, at 10:48 PM, Mike McQuaid notifications@github.com wrote:

Just pushed my own version.


Reply to this email directly or view it on GitHub.

Contributor

halloleo commented Dec 4, 2012

Thanks Mike, for taking care of the git pushing.

On 04/12/2012, at 10:48 PM, Mike McQuaid notifications@github.com wrote:

Just pushed my own version.


Reply to this email directly or view it on GitHub.

snakeyroc3 pushed a commit to snakeyroc3/homebrew that referenced this pull request Dec 17, 2012

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.