Re: Bug#54810: ought to depend on logrotate
(debian-policy CC-ed) On Tue, 11 Jan 2000, Steve Haslam wrote: On Tue, Jan 11, 2000 at 10:10:41PM +0100, Gergely Madarasz wrote: mailman installs a file in /etc/logrotate.d but doesn't depend on logrotate- which means the logs are silently not rotated. it actually recommends logrotate just like many other packages having logrotate config files... so this was intentional... or is there any policy about logrotate ? Actually, I don't know about a policy regarding logrotate. But apt-get doesn't do anything about recommends: fields, so I didn't get it- in fact, I didn't realise it was a separate package until I realised the logs weren't being rotated for months and investigated... Actually I just introduced logrotate support in my last upload, so logs weren't rotated before at all even with logrotate installed... :) Hmm.. actually, there's quite a variation on how packages relate to logrotate: all of Depends, Recommends and Suggests are used. apt-cache showpkg logrotate | perl -lne 'print $1 if (/^ +(.+),logrotate$/)'\ | xargs -n 1 apt-cache show | egrep '(^Package:|logrotate)' helps show that: Suggested by: cron, mysql-server, wwwoffle, wu-ftpd, taper Recommended by: xtide, sympa, smtpfeed, mailman, cricket Depended on by: heimdal-kdc, jserv, syslog-ng, linuxconf, leafnode, fwctl, bsmtpd I see... so I think there should be some policy about logrotate... -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: Bug#53054: pygresql: change version number to reflect correct upstream version
On Sun, 19 Dec 1999, Oliver Elphick wrote: [Forwarded to debian-policy for comments] Juergen A. Erhard wrote: Package: python-pygresql Version: 6.5.3-4 Severity: normal The upstream version of the pygresql package is 2.4, but the upstream version number on this .deb is 6.5.3. This is wrong. Yes, it's just in the packaging manual... yes, that is not policy... *yet* (and looking at policy and the packaging-manual, I think a lot of the latter should actually be in the former). *Please* change this. (Oops, you'll need an epoch... too bad). It has this number because it comes from the upstream PostgreSQL release; it is a binary package from the postgresql source. The upstream PostgreSQL maintainers have included it, as they have pgaccess and the odbc code. It would be equally confusing, therefore, for it not to share the PostgreSQL release number. If I had packaged the PyGreSQL source independently of PostgreSQL, I would agree with you. I don't think it is possible to do what you want except by eliminating this package from PostgreSQL and packaging it separately. It is quite possible though. For example check the slink bash source package which builds libreadlineg2 -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
copyright file problems
Hello, Since I started working on the ftp archive, I've found at least three packages in incoming which come with a licence like this: This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. This might be clear for the experienced linux user/admin, but it does not say anything for beginners, who haven't lived in the free software world for years like us. I've rejected the first two packages from incoming asking to at least point to the corresponding licences in /usr/share/common-licences (I've been called a fascist for this once ;)). I'd like to hear about your opinion on how to handle this case, because this seems to be a problem with quite a lot of packages. Perhaps a policy modification/clarification could help the case. -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: Uploaded alsadriver-unstable 0.5pre+cvs19991024+1855-1 (source all) to master
On Tue, 26 Oct 1999, Masato Taruishi wrote: At Mon, 25 Oct 1999 23:11:18 +0200 (MET DST), Gergely Madarasz [EMAIL PROTECTED] wrote: alsadriver-unstable (0.5pre+cvs19991024+1855-1) unstable; urgency=low . * new upstream release. * Changed section from main to contrib. Why change the sections ? Does it depend on non-free or non-us or other contrib software ? Because that is the only case when it should be put into contrib. The reason why I put it into contrib is that I believe it is too unstable to put it into main section. There is the following sentence in debian then put it into project/experimental policy manual 2.1.3: * packages which we don't want to support because they are too buggy, Is this a wrong change? Hmm... indeed... I thought we sorted this out in the policy already. Btw your policy manual version is a bit outdated. Greg
Re: Why -g flag?
The idea is to build the program with -g -O2, then install it in the debian/tmp tree and strip it. That gets you the following advantages: - The installed binary is stripped and fully optimized. - It's easy to get an unstripped binary: just run debian/build, no makefile tinkering necessary. - The unstripped binary is useful for debugging core files generated by the installed binary. Debug the -O2 optimized program ? I don't think that it's the best debugging method... :) -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/
Re: sources to both contrib main packages
On Tue, 24 Feb 1998, Hamish Moffatt wrote: Some sources produce both main non-main packages. www-sql, for example, produces www-mysql (used to be www-sql) for contrib (since mysql is non-free); currently the www-sql source is in contrib too. Now www-sql can be built for postgresql too, so I will make a binary package www-pgsql. This can go into main because postgresql is DFSG-free, and www-sql itself is GPL. However, dpkg-buildpackage is going to want to build both www-mysql www-pgsql if they're built off the same source; a main source package can't depend on non-main things to build, so it won't be able to build www-mysql. But www-sql must be in main to build www-pgsql for main. The fix seems to be to have two source packages. Is there a better one? dpkg-buildpackage needs multiple binary targets, perhaps. Some other packages were mentioned on debian-devel which have the same problem; ax25utils (has some xforms support), ddd and some others. My php3 packages fall into the same category. I have made a separate source package called php3-contrib which include only the sources needed to build php3-mysql, php3-msql and php3-gd (they depend on non-free libraries) Greg -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/
Re: Repackaging of xforms (now libforms) package(s?)
On 2 Jan 1998, Ben Gertzfield wrote: A few quick questions: I've repackaged the package formerly known as xforms0.86 (it's now libforms) with the upstream libc6 version of the binaries. (There's no source available.) But there's also a newer libforms, 0.88, available. I'm just wondering whether I should follow Debian policy and make two packages: libforms0_0.88-1.deb libforms-dev_0.88-1.deb or three packages, following the old xforms style: libforms0.86_0.86-1.deb libforms0.88_0.88-1.deb libforms-dev_0.88-1.deb If I do the former, it'll be proper Debian policy for libraries. But with the latter, the two libforms0.XX packages will have to conflict with each other, as the /usr/lib/libforms.0 file must be a symlink to the current version of the library. As we discussed on irc... ;) The soname is 0.88 so, no symlinks needed Package names should be libforms0.88 libforms0.88-dev libforms0.86 (this should be the libc5 one) and optionally libforms0.86-altdev ;) -- Madarasz Gergely [EMAIL PROTECTED] [EMAIL PROTECTED] Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/
