Reini Urban schrieb: > Due to popular request I'll change the postgresql layout from the big > monolithic singular package to a layout as used in debian for 8.1 > > This will make it easier for the packages xemacs and php at first, > and for users it will seperate the dll's and the clients from the server. > > Note that at first I will only support one simultaneous postgresql > server package. A debian-like postgresql-common for simultaneous > postgresql server packages (7.4, 8.0, 8.1) is in consideration. > > Attached are the hint files for the packages. > > The only changes from debian are non-versioned names, -dev renamed to > -devel to be consistent with our naming, and postgresql-server-dev > renamed to postgresql-devel.
Before I upload the 13 new postgresql packages, I'll ask a short question how to handle the upcoming conflict resolution, not to make stupid mistake. postgresql-8.1.3-2 setup.hint has: requires: libpq4 postgresql-client crypt libintl3 openssl zlib test: 8.1.3-2 prev: 8.0.7-1 curr: 8.1.3-1 For test: 8.1.3-2 everything is correct. I want to prepare this as test release and therefore bump 8.1.3-1 to curr. For libpq4 and postgresql-client I created empty -8.1.3-1.tar.bz2 files, so that when somebody updates from the old prev 8.0.7-1 to the new current 8.1.3-1 (default behavior), the new empty required client and lib packages will get pulled in. When I bump 8.1.3-2 to curr or someone wants the test release, the new layout will get installed. Should I provide empty 8.0.7-1.tar.bz2 files for those two required packages also? I checked installing 8.1.3-1 locally and updating to 8.1.3-2 also, and everything looked ok, but who knows. Problems: Installing postgresql-8.1.3-2 without installing the test releases libpq4-8.1.3-2 and postgresql-client-8.1.3-2 will ask for trouble. I can only think of providing a copy of libpq4-8.1.3-2 as libpq4-8.1.3-1 (ditto for the clients) to circumvent this.
