Re: One source, two binary packages
Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago Currently, you force to have those tools installed to Santiago everybody who wants to recompile the package. Why is it a problem to require that `autoconf' and `automake' be installed? Once you install the compiler, make, and the library -dev packages, why not just install the auto* programs too, to complete the system? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
On 16 Apr 1998, Karl M. Hegbloom wrote: Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago Currently, you force to have those tools installed to Santiago everybody who wants to recompile the package. Why is it a problem to require that `autoconf' and `automake' be installed? Once you install the compiler, make, and the library -dev packages, why not just install the auto* programs too, to complete the system? It makes the build environment dependant on an unnecessary tool. Automake, autoconf, libtool, and gettext are all designed specifically so they aren't required to rebuild sources using them. Automake changes reasonably frequently (as does libtool) and you can't be sure to get the same version of the tool that you used. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
Scott == Scott Ellis [EMAIL PROTECTED] writes: Scott You actually only need to run it once. Once they've been Scott run once (probably right after porting your changes into a Scott new version), the updated files are left behind and will be Scott included in the diff generated when you build the package. In my experience, making the diff file huge makes porting and new versions unnecessarily difficult. The only way I've been able to keep my sanity with the plethora of GIMP/GTK+ releases is this solution. -- Brought to you by the letters B and V and the number 6. Do you wish to see our *surprising toys*? No! Do not! -- Orz, SCII Ben Gertzfield http://www.imsa.edu/~wilwonka/ Finger me for my public PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
Hi, Bob == Bob Hilliard [EMAIL PROTECTED] writes: Bob I expect to make some minor modifications in the upstream Bob Makefile.in. Should these be mentioned in the copyright file or Bob the changelog? Ummm, changelog, I think, unless it somehow modifies or is relevant to the upstream copyright. manoj -- I don't agree at all with any partisan or other criticism of the United States build-up in Vietnam. Richard M. Nixon, February 15, 1962 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
Your debian/rules should build *both* packages.
Here's the debian/rules from my GIMP packages. It should clear up
your confusion. It uses debhelper judiciously; I'd recommend using
debhelper to save your sanity. :)
#!/usr/bin/make -f
# First, we build the package. The automake/aclocal/autoconf stuff
# isn't important; it's to get around libtool wonkiness. Ignore it. :)
build: build-stamp
build-stamp:
dh_testdir
automake
aclocal
autoconf
# Add here commands to compile the pacckage.
./configure --prefix=/usr
$(MAKE)
touch build-stamp
clean:
dh_testdir
dh_testroot
-rm -f build-stamp install-stamp
# Add here commands to clean up after the build process.
-$(MAKE) clean
-$(MAKE) distclean
rm -rf debian/{gimp,gimp-nonfree,libgimp1,libgimp-dev}
find . -name '*.o' -o -name '_libs' -o -name '*.lo' -o -name '*.a' -o
-name '*.P' -o -name 'Makefile' | xargs rm -rf
-rm app/gimp
dh_clean
# Build architecture-independent files here.
binary-indep: build
# We have nothing to do by default.
# Build architecture-dependent files here.
# Notice how binary-arch has lots of separate targets for the different
# packages that get built! Each one gets built after the 'build'
# and the 'install' targets are run.
binary-arch: build install gimp-nonfree gimp libgimp-dev libgimp1
# This target basically does the 'make install' bit of the package.
# All the individual files for each package are then moved through
# judicious use of dh_movefiles (I HIGHLY recommend using dh_movefiles
# for multi-binary packages; it makes things MUCH easier :)
install: install-stamp
install-stamp: build
dh_testdir
dh_testroot
dh_clean
dh_installdirs usr/X11R6/bin
$(MAKE) prefix=`pwd`/debian/tmp/usr install
mv debian/tmp/usr/bin/gimp debian/tmp/usr/X11R6/bin
touch install-stamp
# The libgimp1 target is missing the dh_movefiles call because it's
# the topmost package target and the last target in binary-arch;
# it basically takes what's left in debian/tmp and packages it up
# for itself.
libgimp1: build install
dh_testdir -plibgimp1
dh_testroot -plibgimp1
dh_installdirs -plibgimp1
rm -rf debian/tmp/usr/bin debian/tmp/usr/X11R6 debian/tmp/usr/include \
debian/tmp/usr/share debian/tmp/usr/lib/*.la
dh_installdocs -plibgimp1
dh_installchangelogs -plibgimp1
dh_strip -plibgimp1
dh_compress -plibgimp1
dh_fixperms -plibgimp1
dh_installdeb -plibgimp1
dh_shlibdeps -plibgimp1
dh_gencontrol -plibgimp1
dh_makeshlibs -plibgimp1 -V
dh_md5sums -plibgimp1
dh_builddeb -plibgimp1
# The rest of the targets use dh_movefiles to move files into debian/package.
# The gimp target moves everything it wants into debian/gimp.
gimp: build install
dh_testdir -pgimp
dh_testroot -pgimp
dh_clean -k -pgimp
dh_installdirs -pgimp usr/X11R6/man/man1
dh_movefiles -pgimp
-rm -f install-stamp
cp docs/gimp.1 debian/gimp/usr/X11R6/man/man1
dh_installdocs -pgimp debian/README.debian docs/*.txt \
README NOTES
dh_installchangelogs -pgimp ChangeLog
dh_strip -pgimp
dh_compress -pgimp
dh_fixperms -pgimp
dh_installmenu -pgimp
dh_installdeb -pgimp
LD_LIBRARY_PATH=$(shell pwd)/debian/tmp/usr/lib dh_shlibdeps -pgimp
dh_gencontrol -pgimp
dh_md5sums -pgimp
dh_builddeb -pgimp
gimp-nonfree: build install
dh_testdir -pgimp-nonfree
dh_testroot -pgimp-nonfree
dh_clean -k -pgimp-nonfree
dh_movefiles -pgimp-nonfree
-rm -f install-stamp
dh_installdirs -pgimp-nonfree
dh_installdocs -pgimp-nonfree
dh_installchangelogs -pgimp-nonfree
dh_strip -pgimp-nonfree
dh_compress -pgimp-nonfree
dh_fixperms -pgimp-nonfree
dh_installdeb -pgimp-nonfree
LD_LIBRARY_PATH=$(shell pwd)/debian/tmp/usr/lib dh_shlibdeps
-pgimp-nonfree
dh_gencontrol -pgimp-nonfree
dh_md5sums -pgimp-nonfree
dh_builddeb -pgimp-nonfree
libgimp-dev: build install
dh_testdir -plibgimp-dev
dh_testroot -plibgimp-dev
dh_clean -plibgimp-dev -k
dh_installdirs -plibgimp-dev
dh_movefiles -plibgimp-dev
-rm -f install-stamp
dh_installdocs -plibgimp-dev
dh_installchangelogs -plibgimp-dev
dh_strip -plibgimp-dev
dh_compress -plibgimp-dev
dh_fixperms -plibgimp-dev
dh_installdeb -plibgimp-dev
dh_shlibdeps -plibgimp-dev
dh_gencontrol -plibgimp-dev
dh_md5sums -plibgimp-dev
dh_builddeb -plibgimp-dev
source diff:
@echo 2 'source and diff are obsolete - use
Re: One source, two binary packages
Ben Gertzfield [EMAIL PROTECTED] writes: Your debian/rules should build *both* packages. Here's the debian/rules from my GIMP packages. It should clear up your confusion. It uses debhelper judiciously; I'd recommend using debhelper to save your sanity. :) Bob, don't fear the reaper. dh_* is great, but if you wanna learn the guts, do it by hand. My jade source package produces 3 binary packages from it, with not a whit of dh_* in sight. Um, that's actually an overly complex example, due to shlibs and dynamic version hackage. Hmm. Maybe my 'mh' package is a better example. Here's my snippet: dpkg-gencontrol -isp -p$(pkg-doc) -P$(prefix-doc) dpkg --build $(prefix-doc) .. dpkg-gencontrol -isp -p$(pkg) dpkg --build $(prefix) .. Manoj has some nice rules files to play around with too. It's possible there's some obscure syntax error in the control file or substvars stuff. .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
Hi, I have this in my directory on master (rules.tar.gz, I think). README follows (the tarball has HTML stuff in it too, meant to be dropped onto the develoers corner web page). manoj __ Here are a set of ./debian directories. A short description follows. All are live debian directories frozen at the time of writing, complete with maintainer scripts and emacs .el files and menu files and all. All the rules files are quite similair; and since I tend to copy a rules file over to a new package area, all my rules files tend to have a very similar look and feel. This should serve well as a learning by example set. Any feedback (espescially patches) shall be appreciated. This is approximately 170K tarred and compressed, and 233K uuencoded. miscfilesJust a bunch of files installed in various places. A bare bones minimalistic package. cvs-buildpackage One of the simplest packages I have kernel-package A relatively simple package. angband-doc A simple derivative of the angband package rules; essentially there are just help files that need to be installed. sgml-baseAlso very simple; the only thing of possible interest is in the rules file where we convert the SGML to text and HTML iff the debaindoc2blah converters are available. make The package I used as a learning tool; in my eyes, this is ``the'' typical package. Also shows you how to get HTML files into a separate package. angband A fairly generic makefile, with the exception that there are a lot of library files involved in a special heirarchy, and some of them need to be conf files. The rules file does not need to know the names of these files, which is good since they change often. c2manA simple package, except that it shows how to deal with a Perl style Configure file. dist A large package, which shows how to deal with a Perl style Configure file. mailagentA Configure style package, with a large examples dir and an in place patch of the binary in the postinst. libcgi-perl A package to handle a typical CPAN style package. This shows how to get the man pages in the correct directories, and all. pkg-orderAnother CPAN style package, with an auto genearation of the version.pl file based on the changelog entry. psgmlAn emacs package, with byte compilation, info files, and a site-stard.d file. vm Another emacs package, with the el files split into another package kernel Complex package showing how kernel paclkages are built. Not something to look at at an early stage of learning about rules files. But it shows the power of the rules file, and what one may do with it latex2html This was difficult to write, and has a few interesting variations. Sets up icons in conformance with the web standard; add things to the TeX heirarchy. -- I would suggest the taxation of all property equally whether church or corporation. --anonymous Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
Manoj Srivastava [EMAIL PROTECTED] writes: I have this in my directory on master (rules.tar.gz, I think). README follows (the tarball has HTML stuff in it too, meant to be dropped onto the develoers corner web page). You should just put this up on the public HTML space on master...? I'm thinking of doing this too for some of my rules file, which I'm also proud of --- especially since I think I'll be able to adapt them to FHS with very little changes. My rules files always start like this: #!/usr/bin/make -f # rules file for doc-base # # I believe in stripped down rules files; nothing that is not required. # I believe in readability through abstraction. package := doc-base # directory abstraction prefix := debian/tmp sbindir := $(prefix)/usr/sbin mandir := $(prefix)/usr/man docdir := $(prefix)/usr/doc/$(package) sharedir:= $(prefix)/usr/share/$(package) vardir := $(prefix)/var/lib/$(package) # build abstraction install_file:= install -o root -g root -m 644 install_script := install -o root -g root -m 755 install_program := install -o root -g root -m 755 --strip make_directory := install -d -o root -g root -m 755 compress:= gzip -9f .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
-BEGIN PGP SIGNED MESSAGE- On 8 Apr 1998, Ben Gertzfield wrote: Here's the debian/rules from my GIMP packages. It should clear up your confusion. It uses debhelper judiciously; I'd recommend using debhelper to save your sanity. :) #!/usr/bin/make -f # First, we build the package. The automake/aclocal/autoconf stuff # isn't important; it's to get around libtool wonkiness. Ignore it. :) build: build-stamp build-stamp: dh_testdir automake aclocal autoconf I disagree here. If you put this in a different debian/rules target (called, for example, automake-refresh), then you and only you would be forced to have automake and autoconf installed, but nobody else. Currently, you force to have those tools installed to everybody who wants to recompile the package. Think about all the GNU packages: They include a configure script which already matches the configure.in, so that the person compiling the package has not to have autoconf installed. I don't see any reason why Debian packages should not take this as a good practice also. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNSyjzSqK7IlOjMLFAQEKEgP/aWKCXaGKjsDGAt9qIl+/VRyZ8cnjel2e XYkCRmmtCX5AwWMaIJUDb49wRIQQuRkfuhqC1DDX4zJv233fO6H5qQj37ezeNpPX 2uNxHF/WW25uqIz6Ds9ygPTWgDNHE1GzDCIo4kvmf/0uUt2URZwuWFYRaqNnMhSu 46RK8eGA6GY= =byEc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago I disagree here. Santiago If you put this in a different debian/rules target Santiago (called, for example, automake-refresh), then you and Santiago only you would be forced to have automake and autoconf Santiago installed, but nobody else. That's why the comment said that it's unnecessary for that package. For the GIMP packages, it is required; they ship with a libtool that is incompatible with Debian policy. I have to run automake/aclocal/autoconf every single time the package builds to remove all vestiges of the old libtool and replace it with the Debian libtool. -- Brought to you by the letters C and Y and the number 17. I put my feet on the Ottoman.. Empire. -- Moxy Fruvous Ben Gertzfield http://www.imsa.edu/~wilwonka/ Finger me for my public PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One source, two binary packages
-BEGIN PGP SIGNED MESSAGE- On 9 Apr 1998, Ben Gertzfield wrote: For the GIMP packages, it is required; they ship with a libtool that is incompatible with Debian policy. I have to run automake/aclocal/autoconf every single time the package builds to remove all vestiges of the old libtool and replace it with the Debian libtool. I still don't understand why this has to be done in the *build* target. Suppose a GNU package has a configure script generated by a buggy autoconf. The Debian maintainer could add a special target in the debian/rules which calls autoconf and refreshes configure from configure.in. Then the package could be created normally, and the new (fixed) configure script would be reflected in the diffs. And then, people compiling the *same* source package for m68k, powerpc, alpha, or whatever do not need to run autoconf again. I don't know much about libtool, but is it so much different than generating configure scripts from configure.in? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNS0XOiqK7IlOjMLFAQE9yAP9GgM+RvmPp+fDOcJ6wopxbjOLkniHoxkm DDK2SAt856tvTl8EhpvX7heB0X0Nq+RdCvvW+SVuXI9JVgtgjXGAaZPT3iEOGIJL EGRspr+8n84yFrMyIdw2eRchfEMJcRlMUbd97CaoBcHE9QdrlKL408/TJHeEZk0o Ukbi9eIcmho= =KqiE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
