On Tue, 22 Feb 2005, Dag Wieers wrote:
On Tue, 22 Feb 2005, Tom 'spot' Callaway wrote:
> On Tue, 2005-02-22 at 11:54 -0500, Chuck R. Anderson wrote:
> >On Tue, Feb 22, 2005 at 10:46:23AM -0600, Tom 'spot' Callaway wrote:
> >> Fedora Extras:
> >> openafs-module
> >> unionfs-module
> >
> >I don't like this. How are we supposed to refer to these packages in
> >the yum configuration for installonly? *-module might collide with
> >other packages that aren't kernel modules (apache module? perl
> >module?). I like kernel-module-unionfs because it is clear that it is
> >a kernel module, and we can use the kernel-module-* glob in yum
> >configuration.
>
> This seems reasonable. Is anyone opposed to:
>
> kernel-module-GFS
> kernel-module-openafs
> kernel-module-unionfs
> kernel-module-ati
> kernel-module-nvidia
Could we also evolve to a lowercase standard for package names ? This
example shows a clear example of why uppercase or mixed case could be
confusing or problematic.
Other distributions already moved (or are evolving) to lower case as the
default. (Even though perl is a good exception where uppercase and strict
names are important)
I once wrote a few documents explaining the package namespace and ideas
about that, including the kernel-module namespace.
http://svn.rpmforge.net/svn/branches/docs/dag/old/naming-convention.txt
http://svn.rpmforge.net/svn/branches/docs/dag/old/renamed-packages.txt
Both have pointers to other projects guidelines regarding naming and
namespace.
The lib%{name} stuff was very controversial back then, even as a
proposal. Whatever policy is chosen, I'm sure that the pragmatic way of
enforcing it would be to start off (or limit it) to new packages only.
The add-on packages is something that is also not yet endorsed by
everyone. The basic idea is to have an add-on package start with the name
it adds something to. Like a python module starts off with python-%{name}
and an xmms plugin starts with xmms-%{name}. Even when it is a sub-package
of %{name} or the original name is slightly different (does/does not
include a prefix or is named the other way around).
I think the biggest difficulty with coming up with a proper naming scheme
is that people want to put that next to the current packages and suddenly
see a lot of things not complying and then object to the proposed
standard. We may have to first acknowledge that the current namespace is
the result of not having a naming convention and acknowledge the fact that
we don't necessarily need to fix everything that already exists to adopt a
naming scheme for new packages.
Kind regards,
-- dag wieers, dag(a)wieers.com,
http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]