Re: Policy for modifier keys?
On 5.X.2001 at 00:36 Panu Kalliokoski wrote: Should there perhaps be a policy about how modifiers keys are mapped in console and X applications? For example, on the console, alt produces an esc prefix, which is IMO good and makes alt equivalent to a meta key. However, under X, meta is usually the windows key, which is a nuisance if one often changes between console and X. You can define your keyboard as a pc102 one (though it's actually pc105 or pc104). This will make the keys Alt to act as Meta. It's a matter of personal preference how one defines his keyboard. Moreover, because X programs can treat modifiers in two ways - the simple one, using modifier number, and the complex one, mapping mod numbers to keycodes and then using those - there probably should be some consistent policy of which mod number is mapped onto which modifier etc. The simple method is not correct. Bugs have to be submitted against such programs. AFAIK Emacs is such a program. Anton Zinoviev, [EMAIL PROTECTED]
Bug#114920: [PROPOSAL] remove foolish consistency in perl module names
Package: debian-policy Rationalle: Perl policy currently dictates that a perl module package have a name of the form lib-foo-bar-perl, where foo-bar maps to Foo:Bar in the perl module name. This is resulting in a lot of very large and awkward package names -- the worst ofender so far is the longest named package in the entire distribution: libbusiness-onlinepayment-bankofamerica-perl There are a lot of other very long package names that result from this foolish consistency, and indeed perl module packages make up 1/5th of all the packages with names in excess of 25 characters. Reducing the size of these packages names will thus have a large impact on the length of Debian's package names in general; this in turn has many ramificatons large and small everywhere users deal with or are exposed to package names. (Typing in libbusiness-onlinepayment-bankofamerica-perl is not fun. Neither is seeing it truncated to 20 characters in dpkg -l.) At the same time, this consistency of package names can indeed be very useful, when things are being automated, and we shouldn't lose that benefit with foolish inconsistency. Proposal: Replace section 3.2 of the perl sub-policy included with Debian policy with the following text: Packages which contain perl modules should provide virtual packages that correspond to the primary module or modules in the package. The naming convention is that for module 'Foo::Bar', the package should provide 'libfoo-bar-perl'. This may be used as the package's name if the result is not too long and cumbersome. Or the package's name may be an abbreviated version, and the longer name put in the Provides field. Also, although they are not currently part of the formal policy, there are conventions to use similar naming for java (and maybe python) module packages, and if this proposal is passed, those informal policies should be updated to work the same way. Transition: There is no need for a transition plan for this proposal. It allows existing packages to remain unchanged, while new packages use shorter names as desired. Existing packages can be renamed to shorter names at their maintainers' discretion, though if they do, they'll have to watch out for versioned dependancies (rare; very little depends on perl module packages at all). Process: I am looking for seconds for this proposal. -- A foolish consistency is the hobgoblin of little minds. -- Ralph Waldo Emerson
Bug#114920: PROPOSAL] remove foolish consistency in perl module names
Joey Hess [EMAIL PROTECTED] wrote:
Proposal:
Replace section 3.2 of the perl sub-policy included with Debian policy
with the following text:
Packages which contain perl modules should provide virtual packages
that correspond to the primary module or modules in the package. The
naming convention is that for module 'Foo::Bar', the package should
provide 'libfoo-bar-perl'. This may be used as the package's name if
the result is not too long and cumbersome. Or the package's name may
be an abbreviated version, and the longer name put in the Provides
field.
I object. Until versioned provides work reliably, doing this prevents
any use of versioned dependencies on such packages which may come back
to haunt us.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#114920: PROPOSAL] remove foolish consistency in perl module names
Herbert Xu wrote: I object. Until versioned provides work reliably, doing this prevents any use of versioned dependencies on such packages which may come back to haunt us. If something needs to declare a versioned dependency, it need only use the package's real name in the dependency. There really arn't that many dependancies on libfoo-perl packages in debian, and the number of versioned dependencies is quite small. Raising the specter of versioned provides sure is a nice way to kill any forward progress at all, ain't it? -- see shy jo
Bug#114920: PROPOSAL] remove foolish consistency in perl module names
On Mon, Oct 08, 2001 at 06:56:30PM -0400, Joey Hess wrote: Raising the specter of versioned provides sure is a nice way to kill any forward progress at all, ain't it? What do you think we have Herbert Xu around for? -- G. Branden Robinson| The greatest productive force is Debian GNU/Linux | human selfishness. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgpfBv7EPOHaw.pgp Description: PGP signature
Bug#114949: debian-policy: inconsistency on /var/spool/mail vs. /var/mail
Package: debian-policy Version: 3.5.6.0 Severity: minor 10.1.3 The system-wide mail directory: The system-wide mail directory is /var/mail. . The use of the old location /var/spool/mail is deprecated and: 12.6 Mail transport, delivery and user agents: ... The mail spool is /var/spool/mail perhaps some clarification here would be appropriate? FHS 5.11 specifies /var/mail as the system mail spool. Cheers, Mike. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux relativity 2.4.7 #1 Sun Aug 5 21:22:04 NZST 2001 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages debian-policy depends on: ii fileutils 4.1-7 GNU file management utilities.
