Hi Jari! Jari Aalto [2005-08-31 20:13 +0300]: > Oops. I didn't notice those symlinks. You mentioned that > postgresql-client-<version> holds the binaries, but > postgresql-common reads: > > Conflicts: postgresql (<< 7.5), > postgresql-client (<< 7.5), > postgresql-7.4 (<< 1:7.4.8-10), > postgresql-8.0 (<< 8.0.3-7) > > which means that lower client packages cannot be used?
It just means that the current version does not work with older versions of the client and server packages. It will work with the current versions (and is in fact required by them). These conflicts ensure that you can never install versions that will not work together. > So, > in order to connect to database (to use 'psql'), I have to > install postgresql-common whose name is > > ... is unintuitive Since you don't actually *want* postgresql-common, you will never have a reason to explicitly ask for it. You want to install e. g. the 8.0 server package (postgresql-8.0) or the 7.4 client package (postgresql-client-7.4), and these will pull in p-common as a dependency. The -common suffix is very common (hehe) in Debian for packages that factor out functionality of several packages. So the name of the package actually does not matter at all for users. > ... and brings utilities (symlinks?) that are not asked for So what, a few symlinks which not everybody will use (but many users will use) do not hurt anybody. > So, from the maintainer (your) point of view I understand > the reluctance to split, but I feel that the coherence of > the packaging system would be improved if there were > consistency and separation of objects like: > > <package>-client > <package>-server There is a separation; postgresql-client-8.0 provides the client part, postgresql-8.0 the server part. The latter is just not called "-server", mainly for historical reasons. > Just like the openssh finally is shipped in separate > packages and not in monolithic "one". In postgresql's case, > it's a bit "doh!, What's postgresql-common?" First, an user shouldn't actually care. Second, the package description says: Description: manager for PostgreSQL database clusters postgresql-common provides a structure under which multiple versions of PostgreSQL may be installed and/or multiple clusters maintained at one time. > - The name implies infrastructure for all postgresql > related > => is it really such package? Sure; it contains all the actual packaging logic which is shared between all server and client versions. > - People searching for client with "apt-cache search" > will not recognize the need to look for > "common" package Since p-common is a dependency, they don't need to. > The end user asks: > > - Okay, I need client. Where is that client package? $ apt-cache search postgresql client postgresql-client-8.0 - front-end programs for PostgreSQL 8.0 postgresql-client-7.4 - front-end programs for PostgreSQL 7.4 [...] > - Okay I need admin tools, Where is that package? apt-cache search postgresql admin will also reveal the client packages, which say Description: front-end programs for PostgreSQL 8.0 This package contains client and administrative programs for PostgreSQL: these are the interactive terminal client psql and programs for creating and removing users and databases. > - Okay I need server, where is that server? Likewise, apt-cache search (or your preferred packaging frontend) will find them. > I don't think it's the size of the package that should be > important, but the packages ability to answer to the needs > of the user. Right. > Even if with 'psql' it is possible to do all the things as with the > individual helper programs, the mental thinking is that "they are > admin utilities" and should belong to "admin package". The distinction between "database usage" and "database administration" is not really sharp; some people might consider creating a database as using it (much the same way as an editor can create new files), other people might regard it as administrative. I don't really see that it would make sense to forcefully rip apart the packages, it would only confuse users, clutter the archive, and give you even more hits when looking for a package. If you think the package descriptions can be improved in any way, I will be happy to tweak them, but I don't want to introduce a categoric split that is done nowhere else for databases. Thanks and have a nice day! Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
