2011/3/14 Brian Bockelman <[log in to unmask]>:
> Kerberos is not in the "BuildRequires" line, so it won't be installed on an automated build system.
Yeah, I added it in the version that I haven't commited yet (+ some
perl dependencies for RHEL6).
> Shoot, sorry, I walked off without completing my thought. I was going to mention that it will help with the pre-releases. That is, there's no way to upgrade from 20110312.73b5e2f to 3.0.3. So, anyone without a precise tagged release is going to get an RPM that must be removed before installling a new xrootd.
>
> What about going halfway? I.e., 3.0.2-git. 20110312.73b5e2f ? It's downright unreadable, but solves the versioning issue.
>
> I think the current schema doesn't provide any way to compare tagged and non-tagged code, does it?
Yes, and this was the intention. We need to discuss what we really
want here. Personally, I would prefer to discourage people from using
non-tagged stuff as much as possible because I end up in the
bug-reproduction-hell if they use whatever they want with whatever
patches they want. Another reason is that what you propose only works
if you have a linear history and it gets messy as soon as you start to
have branches and merges. The 3.0.2 tag can be an ancestor of commits
on many branches, including the development/experimental ones which
may differ radically from master and never get a tag on it's own. We
discussed at some point having a stable and development branch... I
guess we will have to rediscuss all this on Wednesday.
>>> This is the common practice on the OS platform: MySQL, postgres, apache HTTP, etc. It's done by the grid middleware packagers and by other CERN IT projects (CVMFS).
>>
>> And it's a common source of problems for everyone running cluster
>> management systems and having a cetralized account management.
>
> Isn't this something the cluster management folks will have to handle regardless? Or are folks planning on running everything under the "daemon" account? If everything comes out of the box under the daemon account, it becomes the developer's recommendation.
> If it's expected everyone will come later and add a separate 'xrootd' account (whether by hand or automated), then I'd argue it's best to do it in the RPM. All the cluster management systems should add the xrootd account prior to RPM installation or override with their own settings.
Well, I don't like this approach because there is no way to change
the username that the RPM preinst script creates. For instance for
CERN I already have an account called xrootd that I use for
buildbot/coverity/team city/git webservice and others. Other people
may want to call the account dataservice (or whatever) instead of
xrootd, I would prefer to take the least intrusive path here and just
don't create anything.
Lukasz
|
