On Thu, 8 Mar 2012 14:42:48 -0700 Ken Dreyer <[email protected]> wrote:
> Would it be feasible to make this change effective in a major version > release, say, OpenAFS 2.0? Speaking as a user of OpenAFS, the list of > things that must be manually configured has such a high learning curve > to newbies that choosing a useful, modern default would be great. Well, two things: You as an end user don't need to tweak this; $arch_linux26 works. I'm not sure at this point what problem you're trying to solve...? "$arch_linux26 looks funny" doesn't seem very convincing to me... This kind of misnomer happens all the time; arguably even with the first half of your current sysname, called amd64 :) I would imagine this particular case is especially common, since many software projects I expect made a change where they added "Linux 3.* support" by treating 3.* versions the same as 2.6.*. And even if you added an amd64_linux sysname... you'd still need to keep directories called amd64_linux26 etc around, in order for the older clients to make use of them. Secondly, this is easily modifiable by distributions. I think the closest thing Linux has to a "platform" like those of commercial unices (and maybe the BSDs) is a distribution-specific moniker. Just because the OpenAFS project doesn't include anything more specific than "$arch_linux26" by default doesn't mean we can't have a distro-specific tag by default in front of that (and the RPMs related to this thread are already doing that). That seems like a pretty easy way to get more granularity and be more 'modern'. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
