Re: Specifying %{variable} in control file for use in postinst?
Thomas Goirand writes:
> then in your debian/rules build rule, you can do something like:
> MY_VERS=`head -n 1 debian/changelog | cut -d'(' -f2 | cut -d')' -f1 |
> cut -d'-' -f1`
> MY_DEB_REL=`head -n 1 debian/changelog | cut -d'(' -f2 | cut -d')' -f1 |
> cut -d'-' -f2`
> MY_PKGNAME=`head -n 1 debian/changelog | cut -d' ' -f1`
dpkg-parsechangelog makes this somewhat easier and more robust.
--
Russ Allbery (r...@debian.org)
RFS: subversion (updated package) [lenny-backports, 1.6.9dfsg-1~bpo50+1]
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dear mentors/backporters, I am looking for a sponsor for the new version 1.6.9dfsg-1~bpo50+1 of my package "subversion". Since 2010-01-31, the version in "testing" is 1.6.9dfsg-1. This backport omits the optional ra_serf repository access method and uses OpenJDK to build the javahl bindings. Changes: subversion (1.6.9dfsg-1~bpo50+1) lenny-backports; urgency=low . * Rebuild for lenny-backports. * Disable ra_serf, need a newer version than the one in lenny. * Build-depend on libdb4.6-dev, suggest db4.6-util. * Build-depend on openjdk-6-jdk instead of gcj-jdk. * Depend on openjdk-6-jre-headless instead of gij. It builds these binary packages: libapache2-svn - Subversion server modules for Apache libsvn-dev - Development files for Subversion libraries libsvn-doc - Developer documentation for libsvn libsvn-java - Java bindings for Subversion libsvn-perl - Perl bindings for Subversion libsvn-ruby - Ruby bindings for Subversion (dummy package) libsvn-ruby1.8 - Ruby bindings for Subversion libsvn1- Shared libraries used by Subversion python-subversion - Python bindings for Subversion subversion - Advanced version control system subversion-tools - Assorted tools related to Subversion The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/s/subversion - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/s/subversion/subversion_1.6.9dfsg-1~bpo50+1.dsc - - VCS: svn://svn.debian.org/pkg-subversion/1.6.x/ - - VCS browser: http://svn.debian.org/wsvn/pkg-subversion/src/lenny-backports-1.6.x/ I would be glad if someone uploaded this package for me. Kind regards - -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) iEYEAREDAAYFAkvcgjUACgkQcEKlWnqVgz07VQCgopxChM+QQ030Nerljs9ijrdN hEIAni4Lk/TDhnLMdNPXvvM77kbFXpPj =vLNI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdc8237.4070...@elego.de
Re: Specifying %{variable} in control file for use in postinst?
Moving on. As suggested I am simply going to have to hack/kludge rpm and deb with a bunch of sed pre-processing of the respective spec, control and postinst to make it work. These two divergent schemes put a large burden of effort on developers and documenters. Wish I could get deb and rpm folks in the same room and say: can you make this easier to do cross-platform work with both these package systems like linux filesystem standard? DEBIAN is roughly equivalent to SPECS: change to a common third like PACK. SOURCES is practically the same as the root of DEBIAN, change to a common scheme. Unify control file and spec header names they are practically the same thing. -- IV -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l2q311679a81005011007r7b5f677bk4942a416f0bcd...@mail.gmail.com
Re: Status of SIGAR (Was: InVesalius packaging)
On Mon, Mar 29, 2010 at 9:50 PM, Thiago Franco Moraes wrote: ... >> I have limited experience with python packages but the principle is that >> the *.pyc files will be created at package install time in the postinst >> script. This is done by python-support and is described in the Debian >> Python Policy[1]. Perhaps you might have a look into this document and >> if something remains unclear, it is a good idea to ask on >> debian-mentors. >> >> Kind regards >> >> Andreas. >> >> [1] http://www.debian.org/doc/packaging-manuals/python-policy/ >> >> -- >> http://fam-tille.de >> > > Ok, Andreas, I'm reading that. > There is also a python-debian mailing list for those kind of questions: HTH -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/p2nbf0c3b3f1005010738l8e41ef42gea763bf2812f8...@mail.gmail.com
Re: RFS: Various GNUstep packages; looking for a general sponsor
Il giorno Mon, 14 Dec 2009 23:59:05 +0200 Yavor Doganov ha scritto: > I kindly ask anyone who is interested to consider sponsoring the below > packages, and eventually future uploads of core GNUstep (-make, -base, > -gui, -back), hopefully plus other less important ones. Thanks in > advance! I helped GNUstep transitions in Ubuntu (not much work there, rebuilds and checking consistency of the depenency chains), so I could help sponsoring packages. My direct knowledge of the whole GNUstep stack is very limited, though, so I could not be able to directly contribute to the team in other ways. Please let me know :) -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: Specifying %{variable} in control file for use in postinst?
Ignacio Valdes wrote:
> So here is the use case, one that to my knowledge rpm or deb do not
> provide much guidance for and deb does not provide control fields for:
> Package is a vehicle for installing software that can create multiple
> instances. Further, those instances can be very long lived (decades)
> and almost certainly will be updated and migrated in the future to new
> hardware and software. Finally that in the case of a catastrophic
> failure, the metadata of the rpm/deb file such as name of the rpm/deb
> file and versions that created it are barcoded redundantly with the
> instance in an a instance env file that rides within the instance
> directory tree in a known location in order to facilitate recovery and
> maintenance (this last part is already worked out).
>
Both rpm and dpkg support setting-up in chroots.
> rpm because it can access the spec file header information this is
> pretty easy to do. For deb this looks like I am going to have to parse
> the control file to get this information out. Is there any bash
> control file parsers out there?
>
No, parsing the control file might be dangerous, there's nothing that
tells you it wont change format in the future. What's best is to generate
variable for use in your postinst. My example parses the top of the
debian/changelog, but you could do the same with debian/control
#!/bin/sh
set -e
PKG_NAME=__PKG_NAME__
PKG_VERS=__PKG_VERS__
PKG_DEB_REL=__PKG_DEB_REL__
then in your debian/rules build rule, you can do something like:
MY_VERS=`head -n 1 debian/changelog | cut -d'(' -f2 | cut -d')' -f1 |
cut -d'-' -f1`
MY_DEB_REL=`head -n 1 debian/changelog | cut -d'(' -f2 | cut -d')' -f1 |
cut -d'-' -f2`
MY_PKGNAME=`head -n 1 debian/changelog | cut -d' ' -f1`
sed "s/__PKG_NAME__/${MY_PKGNAME}/" debian/master.postinst
>debian/postinst.temp
sed -i "s/__PKG_DEB_REL__/${MY_DEB_REL}/" debian/postinst.temp
sed "s/__PKG_VERS__/${MY_PKGNAME}/" debian/postinst.temp >debian/postinst
Of course, your clean target should remove debian/postinst.temp and
debian/postinst
that way, you can get the variables you need available in your postinst
in a not too ugly way. I believe you can also do the same for debian/config
and all the other maintainer scripts in general.
If you find this very hard to do and think it could have been made more,
simple, well as many highlighted, in a normal situation you don't need
to have access to all of this.
Thomas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bdbd155.2060...@goirand.fr
Re: RFS: amispammer
Hi Ansgar,
2010/5/1 Ansgar Burchardt
> Hi,
>
> Julián Moreno Patiño writes:
>
> > * Package name : amispammer
> > Version : 3.1-1
> >
> > The upload would fix these bugs: 579499
>
> I am not a DD and cannot upload your package, but though I would give
> some comments:
>
> · debian/rules: The override_dh_auto_install target is useless.
> · debian/amispammer.install, debian/amispammer.links:
> Why don't you install the script directly to /usr/bin?
> · debian/control: The last line of the description contains only a
> single dot.
>
Done, I fixed all, I've uploaded it again.
>
> Also some comments about the upstream program:
>
> · 'require "getopt.pl";'
> This is no longer maintained and deprecated. It only exists for
> compatibility with Perl 4(!) programs. getopt.pl suggests
> Getopt::Long or Getopt::Std as alternatives.
>
> · 'system("renice 20 $$ > /dev/null") if ($OSNAME ne "MSWin32");'
> Perl has a setpriority function. See perlfunc(1).
>
> · Use of threads:
> I believe that using Net::DNS::Async instead of starting over 90
> threads for one DNS query each would make more sense. Or use
> Net::RBLClient, a Perl module to query multiple RBLs in parallel.
>
> · auto_get_ip:
> Screen-scraping web pages is likely to break in the future.
> Also using split twice instead of /.../ to directly extract the IP
> address is bad.
>
> · Using "use strict;" and "use warnings;" is usually a good idea.
>
>
Ok, I am going to write to upstream author to suggest these changes.
Kind Regards,
--
Julián Moreno Patiño
Registered GNU Linux User ID 488513
PGP KEY ID 6168BF60
