 |
 |
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