Bug#481976: libaprutil1: do we really need mysql stuff
Stefan Fritsch wrote: >> This seems a bit much. > > mysql-common adds 136k to libmysqlclient15off's 3992k, that's hardly > relevant. I agree that the situation is not optimal but it's better > than the alternatives. And it will be fixed in lenny+1. It's not the diskspace that I'm worried about; it's the way that any DSA for MySQL (like DSA 1608-1 the other day) will generate a new updated version of mysql-common to be tested and approved and rolled out on all those business-critical Stable web servers. Not that I'm in charge of one of those these days (which is why I'm running Testing); and not that I'm arguing to raise the Severity above "wishlist". I recognise that it's too late now for there to be any practical way of avoiding this minor annoyance within the lifespan of Lenny. -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481976: libaprutil1: do we really need mysql stuff
Followup-For: Bug #481976 Package: libaprutil1 Version: 1.2.12+dfsg-7 Just sticking my nose in to point out (in case it hasn't been noticed) that this new dependency means there is now a hard dependency chain all the way from apache2 to mysql-common. apache2 Depends: apache2-mpm-* apache2-mpm-* Depends: libaprutil1 libaprutil1 Depends: libmysqlclient15off libmysqlclient15off Depends: mysql-common This seems a bit much. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (i586) Kernel: Linux 2.6.25.custom Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libaprutil1 depends on: ii libapr1 1.2.12-4 The Apache Portable Runtime Librar ii libc6 2.7-10 GNU C Library: Shared libraries ii libdb4.6 4.6.21-8 Berkeley v4.6 Database Libraries [ ii libexpat1 2.0.1-4XML parsing C library - runtime li ii libldap-2.4-2 2.4.9-1OpenLDAP libraries ii libmysqlclient15off 5.0.51a-6 MySQL database client library ii libpq58.3.3-1PostgreSQL C client library ii libsqlite3-0 3.5.9-3SQLite 3 shared library ii libuuid1 1.40.11-1 universally unique id library libaprutil1 recommends no packages. -- no debconf information -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486855: apache2: outdated package descriptions
Package: apache2
Version: 2.2.9-1
Severity: minor
Tags: patch
Apache 2 is the only version of Apache currently in Debian, so it's
time its package descriptions took responsibility for describing
what it is, instead of saying what it's better than.
Here's a review of the current control file, with suggestions for
package-description improvements throughout. Patch attached, though
I'd be surprised if this draft was good enough.
# Source: apache2
# Section: web
# Priority: optional
# Maintainer: Debian Apache Maintainers
# Uploaders: Tollef Fog Heen <[EMAIL PROTECTED]>, Thom May <[EMAIL PROTECTED]>,
Adam Conrad <[EMAIL PROTECTED]>, Peter Samuelson <[EMAIL PROTECTED]>, Stefan
Fritsch <[EMAIL PROTECTED]>
# Build-Depends: debhelper (>=4.1.16), dpatch, lsb-release, libaprutil1-dev,
libapr1-dev (>= 1.2.7-6), openssl, libpcre3-dev, libtool, mawk, zlib1g-dev,
libssl-dev, sharutils
# Standards-Version: 3.7.3.0
# XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-apache/trunk/apache2
# XS-Vcs-svn: svn://svn.debian.org/pkg-apache/trunk/apache2
# Homepage: http://httpd.apache.org/
#
# Package: apache2.2-common
# Architecture: any
# Depends: ${shlibs:Depends}, ${misc:Depends}, apache2-utils, net-tools,
libmagic1, mime-support, lsb-base, procps [!hurd-i386]
# Suggests: www-browser, apache2-doc
# Conflicts: apache2-common, libapache2-mod-php5 (<= 5.1.6-3),
libapache2-mod-php4 (<= 4:4.4.4-2), libapache2-mod-mime-xattr (<= 0.3-2),
libapache2-mod-mono (<= 1.1.17-3), libapache2-mod-proxy-html (<= 2.4.3-2),
libapache2-mod-scgi (<= 1.11-1), libapache2-mod-speedycgi (<= 2.22-3),
libapache2-modxslt (<= 2005072700-1), libapache2-redirtoservername (<= 0.1-1),
libapache2-webauth (<= 3.5.3-1), libapache2-webkdc (<= 3.5.3-1)
# Replaces: apache2-common
# Description: Next generation, scalable, extendable web server
When I'm reading software descriptions my usual rule of thumb is
that "The Next Generation" means "old hat ten years ago". It's not
quite that bad in this case, but given that the previous generation
was pensioned off to legacy-support years ago, it's about time the
phrase came out of this line.
The word "extendable" is recognised by most dictionaries, but the
form that's usually preferred (and used in apache.org blurbs) is
"extensible".
However, this package synopsis is identical to the one for apache2
(the MPM metapackage)! It would make more sense to leave the
advertising copy out of the short description and concentrate on
identifying the package in terms of how it fits into the suite.
Something like:
Description: Apache HTTP Server common files
"Apache" is just what it's known as for short; officially Apache is
the overarching development project, and this is their HTTP Server.
This seems the neatest way of combining that with a uniform synopsis
style.
# Apache v2 is the next generation of the omnipresent Apache web server. This
# version - a total rewrite - introduces many new improvements, such as
# threading, a new API, IPv6 support, request/response filtering, and more.
# .
# It is also considerably faster, and can be easily extended to provide
services
# other than http.
Stop telling me what it's better than! I don't have the option of
apt-get installing apache1, so this needs to be rephrased in terms
of "absolute" rather than "relative" features.
Moving the advertising from the short description and bulking it out
with more of the apache.org blurbage in the same vein, I'd suggest:
The Apache Software Foundation's goal is to build a secure, efficient and
extensible HTTP server as standards-compliant open source software. The
result has long been the number one web server on the Internet.
(Improvements welcome.) Plus maybe some lists of features, but they
really belong in the long description for the apache2 metapackage
rather than here. This paragraph can stay:
# This package contains all the standard apache2 modules, including SSL
support.
# However, it does *not* include the server itself; for this you need to
# install one of the apache2-mpm-* packages; such as worker or prefork.
Except that last semicolon should be at most a comma.
# Package: apache2-mpm-worker
# Architecture: any
# Depends: ${shlibs:Depends}, apache2.2-common (= ${binary:Version})
# Provides: apache2-mpm, apache2, httpd, httpd-cgi
# Conflicts: apache2-mpm, apache2-common
# Replaces: apache2-mpm-threadpool (<< 2.0.53), apache2-mpm-perchild (<< 2.2.0)
# Description: High speed threaded model for Apache HTTPD
# The worker MPM provides a threaded implementation for Apache HTTPD. It is
# considerably faster than the traditional model, and is the recommended MPM.
# .
# Worker generally is a good choice for high-traffic servers because it
# has a smaller memory footprint than the prefork MPM.
The problem here is that "MPM" is Apache-specific jargon. Not that
knowing the expansion helps much, since the reference to modules
just makes it sound as if the /usr/sbin/apache2 binary can load and
unl
Re: [LCFC] templates://ssl-cert/{templates}
> It will become the 'organisationName' field of the generated SSL certificate. [...] > It will become the 'organisationalUnitName' field of the generated SSL > certificate. These cases of "isation" in amongst the uses of "ization" are irritating. The package's ssleay.cnf has [ req_distinguished_name ] countryName = @CountryName@ stateOrProvinceName = @StateName@ localityName= @LocalityName@ organizationName= @OrganisationName@ organizationalUnitName = @OUName@ commonName = @HostName@ emailAddress= @Email@ That is, it uses en_GB in its internal variables, but in the end it considers the en_US versions (as used in the RFCs) to be the canonical fieldnames. > Package: ssl-cert [...] > This package enables unattended installs of software that > need to create SSL certificates. Software isn't plural. Either a) "of software that needs to" or b) "of packages that need to". -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] templates://ssl-cert/{templates}
Christian Perrier wrote: >> "Country's subdivision" doesn't work. I'd suggest "political >> subdivision". > > Hmmm, I'd prefer "Administrative subdivision" as such things aren't > really "political". They're political(ly determined) rather than objective geographical units, but yes, "administrative" is better. > Of course, these things are complicated in GB as ISO-3166-2 lists > "First level divisions", namely Scotland, England, Wales, Northern > Ireland, Channel Islands, Isle of Man and "Divisions" which are > counties, London boroughs, metropolitan districts unitary authorities, > Northern Ireland and Scotland council areas, ie a big mess of various > things altogether in a category (as we wrote in the iso-codes > package). > > We should probably pick a county to have a good example (for France, I > would pick one of our "Départements"indeed, in the translation, I > picked my home city's Département). > > I'm OK to put "Edinburgh, City of", of course..:-) Edinburgh's a bad example since it isn't obvious what kind of thing that's an example of. >> so I'll assume that approach is standard and suggest the >> DefaultChoice value of "England" instead of "Some-State". > > ...or Scotland..:) I was avoiding that just because it seemed egocentric, but come to think of it "England" would confuse any en_US users who think it covers the whole thing. Given that the "Debian centre of gravity" is near Cambridge, maybe we should use stateOrProvinceName=Cambridgeshire, localityName=Cambridge? -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] templates://ssl-cert/{templates}
Christian Perrier wrote: > Your review should be sent as an answer to this mail. I've got no complaints about the control file. > Template: make-ssl-cert/statename > Type: string > _DefaultChoice: Some-State > _Description: State or province name: > Please enter the name of the country's subdivision to use in the SSL > certificate. > . > It will become the 'stateOrProvinceName' field of the generated SSL > certificate. "Country's subdivision" doesn't work. I'd suggest "political subdivision". Given that the default countryName is GB, it would help if the DefaultChoice entry gave some hint as to how I would be expected to fill this in - "Scotland"? "Lothian & Borders"? "Midlothian"? Or what? I notice that my fellow Edinburgh resident Steve uses "Scotland" in "http://www.debian-administration.org/articles/349";, so I'll assume that approach is standard and suggest the DefaultChoice value of "England" instead of "Some-State". > Type: string > _DefaultChoice: One Organization > _Description: Organisation name: ^ > Please enter the name of the company or organization to use in the SSL > certificate. > . > It will become the 'organisationName' field of the generated SSL certificate. ^ The template-names (which nobody sees) have isation; the fields in the RFCs have ization. I can understand the urge to confuse and annoy en_US users in revenge for SSL's ethnocentric assumption that we all live in towns or cities in states or provinces, but I think it's a bad idea to mix locales like this. Also: surely the obvious example organisation is example.org, instead of this "One Organization"? What would they be doing spelling it like that anyway, if they're specifically in countryName=GB? Okay, I wasn't going to, but I'm changing the DefaultChoice values. Except for "countryName=GB" - it makes sense to remind users from the United Kingdom of Great Britain and Northern Ireland that they shouldn't use "UK", they have to follow the official slightly-broken ISO-3166 standard. Better suggestions for "canonical default localityName" etc welcomed... > Template: make-ssl-cert/ouname [...] > Please enter the name of the division or section of the organization, to use ^ > in the SSL certificate. > . > It will become the 'organisationalUnitName' field of the generated SSL > certificate. Defining, therefore no comma. -- JBR Ankh kak! (Ancient Egyptian blessing) --- ../ssl-cert.old/debian/templates2006-05-18 13:02:20.0 +0100 +++ debian/templates2007-09-23 15:11:41.0 +0100 @@ -1,48 +1,65 @@ Template: make-ssl-cert/countryname Type: string -_Default: GB -_Description: Country Name - The two letter code for your Country. (e.g. GB) (countryName) +_DefaultChoice: GB +_Description: Country code: + Please enter the two-letter ISO-3166 code to use in the SSL certificate. + . + It will become the 'countryName' field of the generated SSL certificate. Template: make-ssl-cert/statename Type: string -_Default: Some-State -_Description: State or Province Name - Your state, county or province. (stateOrProvinceName) +_DefaultChoice: England +_Description: State or province name: + Please enter the name of the political subdivision to use in the SSL + certificate. + . + It will become the 'stateOrProvinceName' field of the generated SSL + certificate. Template: make-ssl-cert/localityname Type: string -_Default: Some-Locality -_Description: Locality Name - The name of the city or town that you live in. (localityName) +_DefaultChoice: Foo City +_Description: Locality name: + Please enter the name of the city or town to use in the SSL certificate. + . + It will become the 'localityName' field of the generated SSL certificate. Template: make-ssl-cert/organisationname Type: string -_Default: One Organization -_Description: Organisation Name - The name of the company or organisation the certificate is for. - (organisationName) +_DefaultChoice: Example.Org +_Description: Organization name: + Please enter the name of the company or organization to use in the SSL + certificate. + . + It will become the 'organizationName' field of the generated SSL certificate. Template: make-ssl-cert/ouname Type: string -_Default: One Organization Unit -_Description: Organisational Unit Name - The Division or section of the organisation the certificate is for. - (organisationalUnitName) +_DefaultChoice: Dept of Exemplification +_Description: Organizational unit name: + Please enter the name of the division or section of the organization to use + in the SSL certificate. + . + It will become the 'organizationalUnitName' field of the generated SSL certificate. Template: make-ssl-cert/hostname Type: string Default: localhost -_Description: Host Name - The host name of the server the certificate is for. This must be filled - in. (commonName) +_Description: Host name: + Please ente
