Re: [Gnu-arch-users] request for slight more permissive category names

[Tom Lord]

    > From: Jeremy Shaw <address@hidden>

    > [2] The debian package name policy is:

    > Package names must consist only of lower case letters (a-z), digits
    > (0-9), plus (+) and minus (-) signs, and periods (.). They must be at
    > least two characters long and must start with an alphanumeric
    > character.

How unfortunate, if accurate.  I mean, it's really cute, sure, to
allow a package name like "42" or "+1" but then to do so precludes
allowing any entry which can be either a number or a package name.

Perhaps you got the policy wrong and "42" isn't allowed but "4a" would
be?  Even if so, it's still an unfortunate choice.   A more
conservative namespace is easier to `grep' for and manipulate in
similar ways.

At any rate, regarding your question:

    > Is there some technical reason that category names are so
    > heavily restricted? I am trying to define a policy for storing
    > debian packages in tla and maintain changes against them. debian
    > package names would map perfectly[1] to category names, except
    > category names can not contain a . or + or start with a
    > number[2]. Obviously, I can do substitutions like use % instead
    > of + and , instead of . but it's a bit annoying.

It is a bit annoying but, consider the policy implications.  If we
liberalize the arch names to accomodate every little thing that comes
along, pretty soon the arch names will be unrestricted.  That will
causes us problems with extending the filesystem layouts of archives,
project trees, revlibs, etc....  It will cause us problems extending
the CLI.  Overall, the bondage of the restricted namespace pays off in
too many ways to embark down a slippery slope of removing too many
restrictions.  If we do want to remove restrictions, doing it to allow
a simpler mapping from some other systems' namespaces is the wrong
reason.

-t