Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=13400





------- Additional Comments From sobukus AT sourcemage.org  2007-03-09 15:32 
-------
Sheesh, Andrew, this is no holy war!
I'm sorry, I'm sorry, I'm sorry, I'm sorry.

Long speeches only offer new proof of my blatant ignorance and unhelpfulness, 
so I make my essential points clear how I see it now -- without the anger and 
impatience I forwared from my friend and without too much prose:

1. A user may want to utilize symlinks for managing his config files, 
possibly 
having some central repo (on another filesystem) and links pointing into that.
We should not put that to question -- it's his _choice_.

2. Sorcery should make that possible by preserving whatever is at the place 
of 
a config file in case admin changed it.

I don't see the sense in the way the distinction is currently made. Symlinks 
always to the dumpster, real files through the check first.
What would make sense to me is that one takes _additional_ care for symlinks 
- 
not reaping it even if the contents didn't change (treat the placement of a 
symlink itself as an admin change).
I don't claim that there is no possible sense in the current unconditional 
deletion, I just don't see it.

All I want is to settle on the intended behaviour of the reaper concerning 
symlinks (obviously including preservation of symlinks;-) and have a patch of 
mine or anyone else's included that implements that. If there are strong 
reasons for the behaviour how it is right now, I'd like to know them.
Of course a symlink is not totally identical with a file and there open the 2 
bits of decision with 4 possibilities (actually, if we want to allow admins 
to 
have symlinks hat can be pointing into the void at the moment of casting, 
there's a bit more).
When there are pitfalls in changing the current works into something 
symlink-friendly, please let's find and name them explicitly.

Now I made half a speech again. Dammit.
Andrew, please ignore the parts that make your blood boil (including that 
offending sentence;-).
I just want to be able to change config files into symlinks and have that 
honored by sorcery. I'll happily rework my patch when we can settle on 
the "right thing".

Jeremy:Sheesh, Andrew, this is no holy war!

Long speeches only offer new proof of my blatant ignorance and unhelpfulness, 
so I make my essential points clear how I see it now -- without the anger and 
impatience I forwared from my friend and without too much prose:

1. A user may want to utilize symlinks for managing his config files, 
possibly 
having some central repo (on another filesystem) and links pointing into that.
We should not put that to question -- it's his _choice_.

2. Sorcery should make that possible by preserving whatever is at the place 
of 
a config file in case admin changed it.

I don't see the sense in the way the distinction is currently made. Symlinks 
always to the dumpster, real files through the check first.
What would make sense to me is that one takes _additional_ care for symlinks 
- 
not reaping it even if the contents didn't change (treat the placement of a 
symlink itself as an admin change).
I don't claim that there is no possible sense in the current implementation, 
I 
just don't see it.

All I want is to settle on the intended behaviour of the reaper concerning 
symlinks (obviously including preservation of symlinks;-) and have a patch of 
mine or anyone else's included that implements that. If there are strong 
reasons for the behaviour how it is right now, I'd like to know them.
Of course a symlink is not totally identical with a file and there open the 2 
bits of decision with 4 possibilities (actually, if we want to allow admins 
to 
have symlinks hat can be pointing into the void at the moment of casting, 
there's a bit more).
When there are be pitfalls in changing the current works into something 
symlink-friendly, please let's find and name them explicitly.

Now I made half a speech again. Dammit.
Andrew, please ignore the parts that make your blood boil (including that 
offending sentence;-).
I just want to be able to change config files into symlinks and have that 
honored by sorcery. I'll happily rework my patch when we can settle on 
the "right thing".

Jeremy:
Of course some thought is needed. I got impatient because I feared the bug 
getting lost after I saw no sign of someone taking notice after two weeks.
And I argue that hardlinks are what one should use anyway.
Symlinks work in situations where hardlinks don't. Hardlinks don't show you 
what they are pointing at unless you start comparing inode numbers.
Looking at the link count of a file doesn't tell you _which_ other hardlink 
points to it (there could be other hardlinks unrelated to the one used as 
config file). Please accept that there may be people who prefer handling the 
initially described situation with symlinks, because there are (I'm counting 
my friend and me now, that makes two, which qualifies for plural;-).

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.