On 8/19/06, Steve Kemp <[EMAIL PROTECTED]> wrote:
> I don't think this is a good idea to place user/admin-edited data there.
> Something in /var or /etc/xen-tools would be a better place for these, I
> think.
Honestly I'd kinda agree, but in the past I found there were problems
with having things in /etc. Merge conflicts due to CVS identifiers,
etc.
I don't understand that. This is about the way how you manage the
xen-tools sources, right? I worked with CVS but no idea what placement
of a directory in my software can lead to merge conflicts.
Since the roles and scripts generally, are arch-independant and
not generally user-editable it makes sense to keep them where they are.
I cannot agree, at least not for the place where the roles script
admins write on their own are stored. I am even not sure if it is
probably against policy.
I understand it is not easy to find a good place, because you have
here a directory
where user editable stuff and package-provided files are mixed together.
Like, in debian.d/roles.d are already some files, but the idea is that the user
can add his own - then you'd have (apart from your CVS things, which I
didn't understand) them mixed up.
I think the package-provided files should kept where they are. But
there should be also an additional place for the user's role scripts.
Why not, in _addition_ to searching in
/usr/lib/xen-tools/$dist.d/roles.d also try to
find /etc/xen-tools/$dist.d/roles.d or /var/xen-tools/$dist.d/roles.d/
and look for role
scripts?
(also, users could add distribution-generic scripts as well in such a
structure!)
maybe they should be searched both before running them, so I can
overwrite/extend package-provided rols scripts with my own -
user-provided script wins and replaces a package-provided one with the
same name.
I could perhaps create symlinks from /etc/xen-tools to matcH:
/etc/xen-tools/debian-hooks.d/ -> /usr/lib/xen-tools/debian.d/roles
etc.
However I'm not sure that improves the situation very much.
as there are already role scripts available, this would be
bad/complicated, also - you need to link every single file, not the
directory - managing this is ugly.
Maybe you should discuss that on debian-policy(AFAIK there is such a
list) they can help with such things like where to place which file or
directory, also in terms of the policy.
Having just one role directory doesn't really work so well since it
is possible that multiple distributions might need different scripts
to do a job - it would be unfair to have to expect a role-writer to
have to code their script for all distributions, or test for it.
only one role directory wasn't my idea, I just don't like the location.
But when I think about it, also a single user-editable role dir (at a
good location like /etc/ or /var ) is not bad:
- everybody who only has one distrbution wouldn't care.
- everybody using multiple distribution, which are similar, can simply
re-use scripts
- everybody using multiple different distributions, just gives his
scripts different names. I can have a centos-webserver and a
debian-webserver role, for example - I have to call xen-create-image
with the right role.
as this would be redundant (e.g. xen-create-image --dist dapper --role
dapper-webserver), someone who needs this often will start writing
case decisions in his role scripts, like you propose.
What do you think? (did I explain that clearly?)
Henning
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
