Some questions
Hi This may be newbie questions, but anyway here goes: We have a commercial system, that we are planing to make available open source (GPL) - right now the plan is to have deb packages and tgz files for the installation. The tgz installation can be broken into a) Executable files b) Database files (eg. *.sql files for generating tables) c) Documentation In order to make updating smooth, it would be nice if this separation could be kept, thus I would like to create 3 packages mysoftware # Contains the executables mysoftware-db # Contains the database scripts mysoftware-doc # Contains the documentation My questions are 1) How do I create a deb package that just drops the documentation in a given directory (eg. it is pure html doc so no man pages are created). I have read as much documentation about the process of making debian packages, and all of it seams evolve around turning software that is installable by normal GNU procedures in to a debian package. Normally our software is installed by a script and removed by another script. So I am wondering if anyone has some pointers to documentation that explains how to write a deb package from scratch without usin the helper tools (as these tools does not seam fit our installation procedure). 2) When you update the database software from, say, version 1.0 to 1.1 then it would be preferable to NOT generate all the tables again (that is, mysoftware-db 1.1 should just alter or extend the tables that mysoftware-db 1.0 created). Can I somehow create a package that depends on earlier versions of itself ? - or is there some other scheme that is used when you are in a situation where software depends on earlier versions of itself ?. Sorry if these a trivial questions to some of you, but I am a skilled programmer not a skilled package maintainer and I have unfortunately been unable to find answers to my questions on the net. Thanks in advance. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some questions
On Tue, 1 Mar 2005 16:51:02 +0100, Romain Beauxis <[EMAIL PROTECTED]> wrote: > Le Mardi 1 Mars 2005 16:34, Lars Roland a écrit : > > 2) When you update the database software from, say, version 1.0 to 1.1 > > then it would be preferable to NOT generate all the tables again (that > > is, mysoftware-db 1.1 should just alter or extend the tables that > > mysoftware-db 1.0 created). Can I somehow create a package that > > depends on earlier versions of itself ? - or is there some other > > scheme that is used when you are in a situation where software depends > > on earlier versions of itself ?. > > Then you can provide an update software within the package that check for the > installed version and perform the required changes by itself, and is run when > updating package. > That is to say, without using the debian package system, but relying on > upstream code. > More over, if you want to provide a tgz stand alone tarball, you'll have to > make this kind of code, so why don't you use it also for the package? Ok thanks - as you say we already provide this possibility so it would be easy to move it to Debian - I was just not aware if it was a acceptable solution, to provide 3rd party updating software. But I guess that it will not be a problem as long as this updating software does not make it impossible to uninstall the Debian package. Regards. Lars Roland
Replacement package
Hi I have created a package that replaces another package, but uses the same dependencies and have the same functionality. Given that I want to maintain a minimum of changes to existing packages I want to know if it is possible to let my package appear to debian as another package. that is: -- Depended package: fastforward_-zarge1: This package depends on qmail_zarge1. Original package: qmail_zarge1- This is the package that other packages depends on also this package depends on fastforward_-zarge1 (circular dependency). My package: qmail_patched1 - I Want this to be a replacement to qmail_zarge1but without changing fastforward_-zarge1 -- Coming from a RPM world I am used to using a provide keyword (that is a keyword that tells the package system that my package provides the same functionality as qmail_zarge1). Can this somehow be done ?. Regards. Lars Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Replacement package
On Tue, 8 Mar 2005 07:38:12 -0600 (CST), elijah wright <[EMAIL PROTECTED]> wrote: > uhh - isn't qmail one of those packages that is licensed in such a way > that you are NOT allowed to distribute patched binary builds or patched > source? > > just a vague recollection, here... isn't that DJB's stuff? Well yes and no - as I understand it you are allowed to distribute it as long as you do not call it Qmail. Anyway I am only creating this package for use in my company, we have almost 40 servers running qmail - Our admin have installed it by source on each of them, so I am just helping him creat a package to do the job. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Replacement package
On Tue, 8 Mar 2005 08:50:13 -0500, Justin Pryzby <[EMAIL PROTECTED]> wrote: > You can uses a Provides: in the control file (providing a non-virtual > package). > > http://www.debian.org/doc/debian-policy/ch-relationships.html > > Justin It is a little more complex than that The original package is named Qmail but its version is named 1.03-zarge1, so all packages that depends on Qmail looks for Qmail >> 1.03-zarge1. This is somewhat annoying because I want my package to be named Qmail and have version number 1.03-patched. If I do this then non of the packages that depends on qmail-1.03-zarge1 can install. So what I really want is some way of mapping the version number of the old package to a new one. Writing Provides: qmail (1.03-zarge1) in the control file does not seam to do the trick Anyway thanks for the feed back, it is not a huge problem and there are other ways around it (like compiling depended packages by hand) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Replacement package
On Tue, 08 Mar 2005 16:48:09 +0100, Sven Mueller <[EMAIL PROTECTED]> wrote: > In this case, you can't use Provides:. dpkg doesn't allow versioned > depends to be resolved by Provides: (and doesn't support versions in the > Provides: statement either). You package is named qmail and the package > you want to replace is named qmail. What's different are the versions. > If other packages depend on qmail (>=1.03-zarge1), then you will have to > provide that: a package named qmail with a version higher than > 1.03-zarge1. For example 1.03.mypatch.1 should be higher than 1.03-zarge11. > > cu, > sven Great - That also make sense, so I will just bump the version number. Thanks for the patience -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Replacement package
On Tue, 08 Mar 2005 15:07:33 -0800, Russ Allbery <[EMAIL PROTECTED]> wrote: > It doesn't really matter, at least to Debian, since it's not for inclusion > in the Debian archive, but for the record this is not a correct > understanding of the license on qmail. It is not covered under the > Artistic License. It is covered under a license that gives you the right > only to download, compile, and install the package on your system, and to > distribute the results of compiling the stock package with no > modifications. > > To do anything else, you have to get permission from DJB, although he's > stated elsewhere that he doesn't think copyright law can prohibit the > distribution of patches or your application of patches to software you're > building yourself. (Note that doesn't include distributing the result.) Ok I see, thanks for pointing thatout (Qmail licence has always been a bit mysterious to me) - but anyway since it is only for internal use in my company, I guess it does not matter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Source package and kernel dependency
Hi all I am creating a package of some software that doing compilation needs to have access to the kernel source (any 2.6 kernel should do). The problem lies in the fact that the Debian kernel source package only dumps tar file in /usr/src/, so setting Build-Depends: kernel-source-2.6.8 Is not enough given that I need to unpack the kernel, copy the config file from /boot into the source directotory (/usr/src/linux/.config) and run make oldconfig make prepare In the kernel source directory before I can compile my software. I see the following 3 solutions: 1) Make a external script needed to compile the package (thereby removing the possibility off making a source package that will work, without a properly configured kernel). 2) Using some sort of precompile scripts (does the deb system even have precompile scripts (in the style of preinst and prerm)) - to ensure that the system system is installed correctly. This will ensure that the source package will compile on any system. 3) Ship the configured kernel source along with the package (crappy solution - but it will of cause work). Any feedback (or even solutions) will be appreciated. Regards. Lars Roland
Re: Source package and kernel dependency
On 4/15/05, Michelle Konzack <[EMAIL PROTECTED]> wrote: > It is not enough, if you use the "kernel-headers-2.6.8" ? > These are installed directly, without a tar.gz' Thanks for the info I fixed the autoconf scripts in the software I am packaging, so it does not have checks for the kernel source - only the headers are checked. This of cause makes compiling the the thing a no brainer - so my problem is solved. I do however have a question related to this: Should I make the package dependent on a kernel-image such as: kernel-image-2.6-386 or do debian have some sort of virtual kernel package that I can make use of to describe that my package depends on a 2.6 kernel to be installed but not a specific image. Another possibility would just be to drop any dependency of a specific kernel image. Any suggestions/comments will be welcome. Regards. Lars Roland.
