-dev package dependency policy
Hi,
I am sponsoring SCIM and I could not answer question from its
maintainer on how FTBFS bug should be resolved for Bug #283047.
Key part of discussion goes as folowing. We need to know what is the
right way to fix this situation.
> - Forwarded message from Ming Hua <[EMAIL PROTECTED]> -
> On Sat, Nov 27, 2004 at 09:03:29AM +0100, Osamu Aoki wrote:
> > On Fri, Nov 26, 2004 at 08:59:21PM -0600, Ming Hua wrote:
> > >
> > > The scim packages are going fine, and scim-uim just got accepted to the
> > > repository by ftp master. However, scim-uim now FTBFS on all arches.
> > > The reason looks like a simple missing build-depends, but it is actually
> > > more complicated.
...
> > > The details can be see at the BTS (bug #283047):
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283047
> > >
> > > The short summary is: scim-uim build-depends on libuim-dev. After the
> > > scim-uim packages are prepared, uim packages enabled m17n support and
> > > libuim-dev indirectly depends on libm17n-0 now (through libuim0).
> > > With this new libuim-dev package, the command
> > > pkg-config --libs "uim >= 0.3.9"
> > > generates "-luim -lm17n" instead of only "-luim" as before.
> > >
> > > However, scim-uim doesn't have libm17n-dev as build-depends, but the
> > > configure script happily generates makefile with commands linking to
> > > libm17n. So the build fails miserably.
... I agree libm17n-dev should depend on libm17n-dev.
> >Package: libuim-dev
> >Section: libdevel
> >Architecture: any
> > - Depends: libuim0 (= ${Source-Version}), uim-common
> > + Depends: libuim0 (= ${Source-Version}), libm17n-dev, uim-common
> >Description: Development files for uim
...
> > I see many -dev packages have this kind of dependency when packages are
> > linked. (Version dep may be needed.)
>
> I read similar opnions in Debian Library Packaging Guide
> (http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#AEN80).
> To quote:
> "The -dev package should depend on all -dev packages for libraries
> that the library package depends upon..."
>
> But this is actually a very strict requirement (since you are pulling in
> many -dev packages you don't even know through dependecies). And it
> generates quite long Depends: list for -dev packages. From what I see,
> few -dev packages follow this practice. For example, our scim-dev
> package don't do this.
>
> I also read somewhere saying this comment is outdated now, altough I
> can't remember where exactly. So I am really not sure what is the right
> way to solve this bug.
Now I could not answer above message and asking help on this list. So
next upload will be a good one for all the packages involved.
Regards,
Osamu
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki <[EMAIL PROTECTED]> wrote: > > > > pkg-config --libs "uim >= 0.3.9" > > > > generates "-luim -lm17n" instead of only "-luim" as before. If the pkg-config file of uim gives a -lm17n, then, first of all, libuim-dev should depend on libm17n-dev. Mike
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 04:53:30PM +0900, Mike Hommey wrote:
> On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki <[EMAIL PROTECTED]>
> wrote:
> > > > > pkg-config --libs "uim >= 0.3.9"
> > > > > generates "-luim -lm17n" instead of only "-luim" as before.
>
> If the pkg-config file of uim gives a -lm17n, then, first of all,
> libuim-dev should depend on libm17n-dev.
OK. How about scim?
[EMAIL PROTECTED]:~$ pkg-config --libs scim
-lscim-1.0
So scim-dev can be as:
> Package: scim-dev
> Section: devel
> Architecture: any
> Depends: scim (= ${Source-Version}), libc6-dev | libc-dev
Osamu
Re: -dev package dependency policy
also sprach Osamu Aoki <[EMAIL PROTECTED]> [2004.11.28.0727 +0100]:
> > > > With this new libuim-dev package, the command pkg-config
> > > > --libs "uim >= 0.3.9" generates "-luim -lm17n" instead of
> > > > only "-luim" as before.
pkg-config can specify dependencies. In this case, libuim-dev should
depend on libm17n-dev.
> > > > However, scim-uim doesn't have libm17n-dev as build-depends,
uim states in its pkg-config file that it needs m17n, so therefore
it has to depend on m17n. scim should not need to depend on this.
> > > - Depends: libuim0 (= ${Source-Version}), uim-common
> > > + Depends: libuim0 (= ${Source-Version}), libm17n-dev, uim-common
precisely.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' :proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
signature.asc
Description: Digital signature
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 09:06:33AM +0100, Osamu Aoki <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 28, 2004 at 04:53:30PM +0900, Mike Hommey wrote:
> > On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki <[EMAIL PROTECTED]>
> > wrote:
> > > > > > pkg-config --libs "uim >= 0.3.9"
> > > > > > generates "-luim -lm17n" instead of only "-luim" as before.
> >
> > If the pkg-config file of uim gives a -lm17n, then, first of all,
> > libuim-dev should depend on libm17n-dev.
>
> OK. How about scim?
>
> [EMAIL PROTECTED]:~$ pkg-config --libs scim
> -lscim-1.0
>
> So scim-dev can be as:
>
> > Package: scim-dev
> > Section: devel
> > Architecture: any
> > Depends: scim (= ${Source-Version}), libc6-dev | libc-dev
Well, that'd depend on the content of the header files of scim. If they
include some other stuff, you must depend on this other stuff.
Mike
Re: SRPM to deb conversion standard practices and hints
On Sat, Nov 27, 2004 at 11:11:38PM +0100, Osamu Aoki wrote: > Hi, > > Since many GNU/Linux softwares are initially provided not onlr *.tar.gz > but also they come with SRPM, is there any guide to use them as a good > tem,plate to develop Debian package effeciently. > > It does not need to be point-by-point guide but some collection of > hints. > > Do you know anything for this. > > http://kernellabo.alioth.debian.org/kernellabo/ > > seem to have some script focused on kernel SRPM. > > But I am just lazy packager looking for easy way out :-) > The nearest thing I can think of is alien. Not sure if it is not focused only on rpm and not on srpm. My experience with rpm and srpm is practically nothing. Hopefully you will get better replies.
Re: SRPM to deb conversion standard practices and hints
On Sun, Nov 28, 2004 at 02:28:09PM +0200, Shaul Karl wrote: > On Sat, Nov 27, 2004 at 11:11:38PM +0100, Osamu Aoki wrote: > > Hi, > > > > Since many GNU/Linux softwares are initially provided not onlr *.tar.gz > > but also they come with SRPM, is there any guide to use them as a good > > tem,plate to develop Debian package effeciently. > > > > It does not need to be point-by-point guide but some collection of > > hints. > > > > Do you know anything for this. > > > > http://kernellabo.alioth.debian.org/kernellabo/ > > > > seem to have some script focused on kernel SRPM. > > > > But I am just lazy packager looking for easy way out :-) > > The nearest thing I can think of is alien. Not sure if it is not > focused only on rpm and not on srpm. > My experience with rpm and srpm is practically nothing. Hopefully you > will get better replies. No that is for binary package. You can run it but it just repackage into deb or tar.gz format with spec file and tar.gz file in it. Not much useful. (Just creating control file skelton) rpm2cpio is good enough for this. I am looking for a guide on how to convert spec file beyond Name:, Summary:, and %description. I mean that I am looking for dependency and script conversion after %prep. These scripts are somewhat self explanatory but Osamu
advice about splitting a package (libtiff-tools)
The libtiff package (upstream) includes one program, tiffgt, that requires opengl. The current version of libtiff in debian installs tiffgt's manual page but does not install tiffgt. (This is bug 219456.) I have built new libtiff packages that create tiffgt, which seems like a reasonable program to include. I have two packaging choices, both of which I have successfully implemented, but I wanted some opinions on which way was better. 1. Just add the necessary libraries to Build-Depends so that tiffgt gets built. This is the easiest solution, but it has the disadvantage of having libtiff-tools get a bunch of extra dependencies (X and opengl libraries) just to support one program. 2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where the latter contains only tiffgt and its manual page. This is also really easy, but there's one catch: older versions of libtiff-tools already include the manual page for tiffgt, which means libtiff-opengl must conflict with versions of libtiff-tools that are older than this new version. This means that someone installing libtiff-opengl without first upgrading libtiff-tools will have libtiff-tools REMOVED. To work around this, I could make libtiff-opengl require libtiff-tools >= the minimum version instead of making it conflict with the old version, but I don't want to do this because libtiff-opengl doesn't actually depend upon libtiff-tools. So, should I include tiffgt in libtiff-tools and just not worry about all the new dependencies, or should I deal with this short-lived but annoying problem of people possibly installing libtiff-opengl without first upgrading libtiff-tools and losing libtiff-tools as a result? Most people will have all those libraries on their systems anyway, and I suspect not many people running systems without X will bother with libtiff-tools. Thanks for any advice. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: [Pkg-ime-devel] -dev package dependency policy
Hi, "The -dev package should depend on all -dev packages for libraries that the library package depends upon..." But this is actually a very strict requirement (since you are pulling in many -dev packages you don't even know through dependecies). And it generates quite long Depends: list for -dev packages. From what I see, few -dev packages follow this practice. For example, our scim-dev package don't do this. The point behind this requirement is that library header files include library header files from other libraries, and so depend functionally on the presence of these header files, even if this dependency may not be required for the part of the API the application is using. Thus, the application's build-dependencies would be too broad (since it doesn't use the library, why should it depend on it), but nevertheless neccessary since the unneeded parts in the header file would still fail to compile. The only packages that can be omitted here are build-essential packages. In essence, this means that if your library depends on another library and this is reflected in the header files (which it obviously is), your -dev package needs to depend on the other library's -dev package. Simon
Re: advice about splitting a package (libtiff-tools)
I think I'll reply to my own post. I brought this up on IRC and was pointed to a better solution. > The libtiff package (upstream) includes one program, tiffgt, that > requires opengl. The current version of libtiff in debian installs > tiffgt's manual page but does not install tiffgt. (This is bug > 219456.) I have built new libtiff packages that create tiffgt, which > seems like a reasonable program to include. I have two packaging > choices, both of which I have successfully implemented, but I wanted > some opinions on which way was better. > >1. Just add the necessary libraries to Build-Depends so that tiffgt >gets built. This is the easiest solution, but it has the >disadvantage of having libtiff-tools get a bunch of extra >dependencies (X and opengl libraries) just to support one >program. > >2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where >the latter contains only tiffgt and its manual page. This is >also really easy, but there's one catch: older versions of >libtiff-tools already include the manual page for tiffgt, which >means libtiff-opengl must conflict with versions of libtiff-tools >that are older than this new version. This means that someone >installing libtiff-opengl without first upgrading libtiff-tools >will have libtiff-tools REMOVED. To work around this, I could >make libtiff-opengl require libtiff-tools >= the minimum version >instead of making it conflict with the old version, but I don't >want to do this because libtiff-opengl doesn't actually depend >upon libtiff-tools. > > So, should I include tiffgt in libtiff-tools and just not worry about > all the new dependencies, or should I deal with this short-lived but > annoying problem of people possibly installing libtiff-opengl without > first upgrading libtiff-tools and losing libtiff-tools as a result? > Most people will have all those libraries on their systems anyway, and > I suspect not many people running systems without X will bother with > libtiff-tools. Use Replaces instead of Conflicts. This will enable the new libtiff-opengl to overwrite and claim ownership of tiffgt.1.gz. Since Replaces will appear without Conflicts, libtiff-tools won't get removed. When it gets upgraded, tiffgt.1.gz will not be removed. Once libtiff-opengl is installed, it will no longer be possible to install an older version of libtiff-tools, but I don't consider that to be important. > Thanks for any advice. You're welcome. Actually, thank doogie on IRC. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: [Pkg-ime-devel] -dev package dependency policy
On Sun, Nov 28, 2004 at 07:17:34PM +0100, Simon Richter wrote: > >> "The -dev package should depend on all -dev packages for libraries > >> that the library package depends upon..." > >>But this is actually a very strict requirement (since you are pulling in > >>many -dev packages you don't even know through dependecies). And it > >>generates quite long Depends: list for -dev packages. From what I see, > >>few -dev packages follow this practice. For example, our scim-dev > >>package don't do this. > The point behind this requirement is that library header files include > library header files from other libraries, and so depend functionally on > the presence of these header files, even if this dependency may not be > required for the part of the API the application is using. Thus, the > application's build-dependencies would be too broad (since it doesn't > use the library, why should it depend on it), but nevertheless > neccessary since the unneeded parts in the header file would still fail > to compile. The only packages that can be omitted here are > build-essential packages. > In essence, this means that if your library depends on another library > and this is reflected in the header files (which it obviously is), your > -dev package needs to depend on the other library's -dev package. In practice, I think it's relatively uncommon for headers from one library to require headers from other dependency libraries, which is why such -dev interdependencies are not as common as they might be. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Question concerning conffiles
Hi, I'm trying to build a package in Debian Woody, I have only one file in conffiles '/etc/clamsmtp/clamsmtpd.conf', file clamsmtpd.conf is in the same directory as conffiles.After issuing command dpkg-buildpackage I get an error "dpkg-deb: conffile '/etc/clamsmtp/clamsmtpd.conf' does not apper in package.Could anyone possibly tell me where shall I put file clamsmtpd.conf to avoid this error? Thanx
Re: Question concerning conffiles
"conffiles" are a special case of "configuration files". They are updated gracefully by the package management system: users are prompted during a package upgrade *only* if 1) the upstream package maintainer updated the conffile and 2) *they* customized the conffile for their own system. A configuration file is, at present, defined as any file in /etc/. (correct if me I'm wrong; I think there are plans to support a generalization of this in the future). A configuration file tagged as a conffile (by debhelper) when it is listed in debian/conffiles. Then, the package maintainer must provide a default file in the location specified by debian/conffiles. So, you need to make sure that debhelper is installing a file called '/etc/clamsmtp/clamsmtpd.conf'. If that doesn't fit your needs, then you shouldn't be using a conffile (instead: a configuration file). Justin On Mon, Nov 29, 2004 at 01:14:15AM +0100, [EMAIL PROTECTED] wrote: > Hi, I'm trying to build a package in Debian Woody, I have only one file in > conffiles > '/etc/clamsmtp/clamsmtpd.conf', file clamsmtpd.conf is in the same directory > as conffiles.After issuing command dpkg-buildpackage I get an error > "dpkg-deb: conffile '/etc/clamsmtp/clamsmtpd.conf' does not apper in > package.Could anyone possibly tell me where shall I put file clamsmtpd.conf > to avoid this error? Thanx > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Justin aptitude install task-iraf saods9 eclipse sextractor x11iraf wcstools http://www.justinpryzby.com/debian/ References [1]
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 04:53:30PM +0900, Mike Hommey wrote:
> On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki <[EMAIL PROTECTED]>
> wrote:
> > > > > pkg-config --libs "uim >= 0.3.9"
> > > > > generates "-luim -lm17n" instead of only "-luim" as before.
>
> If the pkg-config file of uim gives a -lm17n, then, first of all,
> libuim-dev should depend on libm17n-dev.
OK. How about scim?
[EMAIL PROTECTED]:~$ pkg-config --libs scim
-lscim-1.0
So scim-dev can be as:
> Package: scim-dev
> Section: devel
> Architecture: any
> Depends: scim (= ${Source-Version}), libc6-dev | libc-dev
Osamu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -dev package dependency policy
also sprach Osamu Aoki <[EMAIL PROTECTED]> [2004.11.28.0727 +0100]:
> > > > With this new libuim-dev package, the command pkg-config
> > > > --libs "uim >= 0.3.9" generates "-luim -lm17n" instead of
> > > > only "-luim" as before.
pkg-config can specify dependencies. In this case, libuim-dev should
depend on libm17n-dev.
> > > > However, scim-uim doesn't have libm17n-dev as build-depends,
uim states in its pkg-config file that it needs m17n, so therefore
it has to depend on m17n. scim should not need to depend on this.
> > > - Depends: libuim0 (= ${Source-Version}), uim-common
> > > + Depends: libuim0 (= ${Source-Version}), libm17n-dev, uim-common
precisely.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' :proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
signature.asc
Description: Digital signature
Re: -dev package dependency policy
On Sun, Nov 28, 2004 at 09:06:33AM +0100, Osamu Aoki <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 28, 2004 at 04:53:30PM +0900, Mike Hommey wrote:
> > On Sun, Nov 28, 2004 at 07:27:20AM +0100, Osamu Aoki <[EMAIL PROTECTED]>
> > wrote:
> > > > > > pkg-config --libs "uim >= 0.3.9"
> > > > > > generates "-luim -lm17n" instead of only "-luim" as before.
> >
> > If the pkg-config file of uim gives a -lm17n, then, first of all,
> > libuim-dev should depend on libm17n-dev.
>
> OK. How about scim?
>
> [EMAIL PROTECTED]:~$ pkg-config --libs scim
> -lscim-1.0
>
> So scim-dev can be as:
>
> > Package: scim-dev
> > Section: devel
> > Architecture: any
> > Depends: scim (= ${Source-Version}), libc6-dev | libc-dev
Well, that'd depend on the content of the header files of scim. If they
include some other stuff, you must depend on this other stuff.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SRPM to deb conversion standard practices and hints
On Sat, Nov 27, 2004 at 11:11:38PM +0100, Osamu Aoki wrote: > Hi, > > Since many GNU/Linux softwares are initially provided not onlr *.tar.gz > but also they come with SRPM, is there any guide to use them as a good > tem,plate to develop Debian package effeciently. > > It does not need to be point-by-point guide but some collection of > hints. > > Do you know anything for this. > > http://kernellabo.alioth.debian.org/kernellabo/ > > seem to have some script focused on kernel SRPM. > > But I am just lazy packager looking for easy way out :-) > The nearest thing I can think of is alien. Not sure if it is not focused only on rpm and not on srpm. My experience with rpm and srpm is practically nothing. Hopefully you will get better replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SRPM to deb conversion standard practices and hints
On Sun, Nov 28, 2004 at 02:28:09PM +0200, Shaul Karl wrote: > On Sat, Nov 27, 2004 at 11:11:38PM +0100, Osamu Aoki wrote: > > Hi, > > > > Since many GNU/Linux softwares are initially provided not onlr *.tar.gz > > but also they come with SRPM, is there any guide to use them as a good > > tem,plate to develop Debian package effeciently. > > > > It does not need to be point-by-point guide but some collection of > > hints. > > > > Do you know anything for this. > > > > http://kernellabo.alioth.debian.org/kernellabo/ > > > > seem to have some script focused on kernel SRPM. > > > > But I am just lazy packager looking for easy way out :-) > > The nearest thing I can think of is alien. Not sure if it is not > focused only on rpm and not on srpm. > My experience with rpm and srpm is practically nothing. Hopefully you > will get better replies. No that is for binary package. You can run it but it just repackage into deb or tar.gz format with spec file and tar.gz file in it. Not much useful. (Just creating control file skelton) rpm2cpio is good enough for this. I am looking for a guide on how to convert spec file beyond Name:, Summary:, and %description. I mean that I am looking for dependency and script conversion after %prep. These scripts are somewhat self explanatory but Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
advice about splitting a package (libtiff-tools)
The libtiff package (upstream) includes one program, tiffgt, that requires opengl. The current version of libtiff in debian installs tiffgt's manual page but does not install tiffgt. (This is bug 219456.) I have built new libtiff packages that create tiffgt, which seems like a reasonable program to include. I have two packaging choices, both of which I have successfully implemented, but I wanted some opinions on which way was better. 1. Just add the necessary libraries to Build-Depends so that tiffgt gets built. This is the easiest solution, but it has the disadvantage of having libtiff-tools get a bunch of extra dependencies (X and opengl libraries) just to support one program. 2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where the latter contains only tiffgt and its manual page. This is also really easy, but there's one catch: older versions of libtiff-tools already include the manual page for tiffgt, which means libtiff-opengl must conflict with versions of libtiff-tools that are older than this new version. This means that someone installing libtiff-opengl without first upgrading libtiff-tools will have libtiff-tools REMOVED. To work around this, I could make libtiff-opengl require libtiff-tools >= the minimum version instead of making it conflict with the old version, but I don't want to do this because libtiff-opengl doesn't actually depend upon libtiff-tools. So, should I include tiffgt in libtiff-tools and just not worry about all the new dependencies, or should I deal with this short-lived but annoying problem of people possibly installing libtiff-opengl without first upgrading libtiff-tools and losing libtiff-tools as a result? Most people will have all those libraries on their systems anyway, and I suspect not many people running systems without X will bother with libtiff-tools. Thanks for any advice. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-ime-devel] -dev package dependency policy
Hi, "The -dev package should depend on all -dev packages for libraries that the library package depends upon..." But this is actually a very strict requirement (since you are pulling in many -dev packages you don't even know through dependecies). And it generates quite long Depends: list for -dev packages. From what I see, few -dev packages follow this practice. For example, our scim-dev package don't do this. The point behind this requirement is that library header files include library header files from other libraries, and so depend functionally on the presence of these header files, even if this dependency may not be required for the part of the API the application is using. Thus, the application's build-dependencies would be too broad (since it doesn't use the library, why should it depend on it), but nevertheless neccessary since the unneeded parts in the header file would still fail to compile. The only packages that can be omitted here are build-essential packages. In essence, this means that if your library depends on another library and this is reflected in the header files (which it obviously is), your -dev package needs to depend on the other library's -dev package. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice about splitting a package (libtiff-tools)
I think I'll reply to my own post. I brought this up on IRC and was pointed to a better solution. > The libtiff package (upstream) includes one program, tiffgt, that > requires opengl. The current version of libtiff in debian installs > tiffgt's manual page but does not install tiffgt. (This is bug > 219456.) I have built new libtiff packages that create tiffgt, which > seems like a reasonable program to include. I have two packaging > choices, both of which I have successfully implemented, but I wanted > some opinions on which way was better. > >1. Just add the necessary libraries to Build-Depends so that tiffgt >gets built. This is the easiest solution, but it has the >disadvantage of having libtiff-tools get a bunch of extra >dependencies (X and opengl libraries) just to support one >program. > >2. Split libtiff-tools into libtiff-tools and libtiff-opengl, where >the latter contains only tiffgt and its manual page. This is >also really easy, but there's one catch: older versions of >libtiff-tools already include the manual page for tiffgt, which >means libtiff-opengl must conflict with versions of libtiff-tools >that are older than this new version. This means that someone >installing libtiff-opengl without first upgrading libtiff-tools >will have libtiff-tools REMOVED. To work around this, I could >make libtiff-opengl require libtiff-tools >= the minimum version >instead of making it conflict with the old version, but I don't >want to do this because libtiff-opengl doesn't actually depend >upon libtiff-tools. > > So, should I include tiffgt in libtiff-tools and just not worry about > all the new dependencies, or should I deal with this short-lived but > annoying problem of people possibly installing libtiff-opengl without > first upgrading libtiff-tools and losing libtiff-tools as a result? > Most people will have all those libraries on their systems anyway, and > I suspect not many people running systems without X will bother with > libtiff-tools. Use Replaces instead of Conflicts. This will enable the new libtiff-opengl to overwrite and claim ownership of tiffgt.1.gz. Since Replaces will appear without Conflicts, libtiff-tools won't get removed. When it gets upgraded, tiffgt.1.gz will not be removed. Once libtiff-opengl is installed, it will no longer be possible to install an older version of libtiff-tools, but I don't consider that to be important. > Thanks for any advice. You're welcome. Actually, thank doogie on IRC. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-ime-devel] -dev package dependency policy
On Sun, Nov 28, 2004 at 07:17:34PM +0100, Simon Richter wrote: > >> "The -dev package should depend on all -dev packages for libraries > >> that the library package depends upon..." > >>But this is actually a very strict requirement (since you are pulling in > >>many -dev packages you don't even know through dependecies). And it > >>generates quite long Depends: list for -dev packages. From what I see, > >>few -dev packages follow this practice. For example, our scim-dev > >>package don't do this. > The point behind this requirement is that library header files include > library header files from other libraries, and so depend functionally on > the presence of these header files, even if this dependency may not be > required for the part of the API the application is using. Thus, the > application's build-dependencies would be too broad (since it doesn't > use the library, why should it depend on it), but nevertheless > neccessary since the unneeded parts in the header file would still fail > to compile. The only packages that can be omitted here are > build-essential packages. > In essence, this means that if your library depends on another library > and this is reflected in the header files (which it obviously is), your > -dev package needs to depend on the other library's -dev package. In practice, I think it's relatively uncommon for headers from one library to require headers from other dependency libraries, which is why such -dev interdependencies are not as common as they might be. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Question concerning conffiles
Hi, I'm trying to build a package in Debian Woody, I have only one file in conffiles '/etc/clamsmtp/clamsmtpd.conf', file clamsmtpd.conf is in the same directory as conffiles.After issuing command dpkg-buildpackage I get an error "dpkg-deb: conffile '/etc/clamsmtp/clamsmtpd.conf' does not apper in package.Could anyone possibly tell me where shall I put file clamsmtpd.conf to avoid this error? Thanx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question concerning conffiles
"conffiles" are a special case of "configuration files". They are updated gracefully by the package management system: users are prompted during a package upgrade *only* if 1) the upstream package maintainer updated the conffile and 2) *they* customized the conffile for their own system. A configuration file is, at present, defined as any file in /etc/. (correct if me I'm wrong; I think there are plans to support a generalization of this in the future). A configuration file tagged as a conffile (by debhelper) when it is listed in debian/conffiles. Then, the package maintainer must provide a default file in the location specified by debian/conffiles. So, you need to make sure that debhelper is installing a file called '/etc/clamsmtp/clamsmtpd.conf'. If that doesn't fit your needs, then you shouldn't be using a conffile (instead: a configuration file). Justin On Mon, Nov 29, 2004 at 01:14:15AM +0100, [EMAIL PROTECTED] wrote: > Hi, I'm trying to build a package in Debian Woody, I have only one file in > conffiles > '/etc/clamsmtp/clamsmtpd.conf', file clamsmtpd.conf is in the same directory > as conffiles.After issuing command dpkg-buildpackage I get an error > "dpkg-deb: conffile '/etc/clamsmtp/clamsmtpd.conf' does not apper in > package.Could anyone possibly tell me where shall I put file clamsmtpd.conf > to avoid this error? Thanx > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Justin aptitude install task-iraf saods9 eclipse sextractor x11iraf wcstools http://www.justinpryzby.com/debian/ References [1] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
