Dependency problem
Hi! Is it possible to specify the following type of package dependency? Either python-wxgtk2.8 or python-qt4 and python-qt4-gl or python-fltk or python-gtk2 and python-gtkglext1 Or would I need to create meta-packages and use something like: python-wxgtk2.8 | python-qt4-and-qt4-gl-meta | python-fltk | python-gtk2-and-gtkglext1-meta where python-qt4-and-qt4-gl-meta would depend on python-qt4 and python-qt4-gl and python-gtk2-and-gtkglext1-meta would depend on python-gtk2 and python-gtkglext1 Thanks Torquil Sørensen -- 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/4e43faaa.4030...@gmail.com
Re: Dependency problem
* Torquil Macdonald Sørensen torq...@gmail.com, 2011-08-11, 17:52: Either python-wxgtk2.8 or python-qt4 and python-qt4-gl or python-fltk or python-gtk2 and python-gtkglext1 You can use something as ugly as: Depends: python-wxgtk2.8 | python-qt4 | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4 | python-fltk | python-gtkglext1, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtkglext1 -- Jakub Wilk -- 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/20110811162311.gb4...@jwilk.net
Re: Dependency problem
On 11/08/11 18:23, Jakub Wilk wrote: * Torquil Macdonald Sørensen torq...@gmail.com, 2011-08-11, 17:52: Either python-wxgtk2.8 or python-qt4 and python-qt4-gl or python-fltk or python-gtk2 and python-gtkglext1 You can use something as ugly as: Depends: python-wxgtk2.8 | python-qt4 | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4 | python-fltk | python-gtkglext1, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtkglext1 I wish I could do something as simple as Depends: python-wxgtk2.8 | (python-qt4, python-qt4-gl) | python-fltk | (python-gtk2, gtkglext1) A priority system would need to be defined, of course. If only python-qt4-gl was already installed, apt would e.g. select to resolve the dependency by installing python-qt4. If e.g. only python-wxgtk2.8 and python-qt4-gl was installed, nothing would need to be done. This is for a program that has a choice of four frontends. WX, QT, FLTK or GTK, which it autodetects at runtime in a particular order of priority. For QT to work, those two QT packages must be installed. For GTK to work, the pair of GTK packages mentioned above must be installed. However, the WX and FLTK frontends only need one package each for the corresponding frontends to work. Perhaps I'll just force the user to install the WX frontend, and list the all others as suggested packages... Torquil -- 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/4e440ba2.1050...@gmail.com
Re: Dependency problem
[...] You can use something as ugly as: Depends: python-wxgtk2.8 | python-qt4 | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4 | python-fltk | python-gtkglext1, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtkglext1 [...] Perhaps I'll just force the user to install the WX frontend, and list the all others as suggested packages... Given that python-qt4-gl already depends on python-qt4 the above list given by Jakub actually shrinks to half. This resulting two-liner doesn't seem too bad after all. Best, Michael pgpmvLYeX0ZvF.pgp Description: PGP signature
Re: Dependency problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.08.2011 19:04, Torquil Macdonald Sørensen wrote: I wish I could do something as simple as Depends: python-wxgtk2.8 | (python-qt4, python-qt4-gl) | python-fltk | (python-gtk2, gtkglext1) I'm pretty sure someone suggested such a syntax already once. Perhaps I'll just force the user to install the WX frontend, and list the all others as suggested packages... Don't do that. Its wrong in several ways. Suggests does not declare alternatives but enhance functionality (policy § 7.2). In your case its a dependency, even if satisfied by another package. Given that, you don't enhance anything by installing your suggested packages. Moreover you possibly force your users to install a hard dependency even though it would be perfectly valid to have only one of the suggested alternatives installed. Use jwilk's suggestion, being ugly or not its the correct one. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJORBQgAAoJEMcrUe6dgPNtOLgQAMRcf4zf3xf3hF/sKWs8uEME V9uSgtz/gqB+NZROFaslkCtpFmxRAtxNf+lv8ad3abj+LeeUlmEe5rtCt75lXUOQ V8U2SdVK9+byoa/4akOdIRuk201gdA23o3OiPLNCAIl8L2iPd5lM06kjERuCCLd3 vfIWknDZmc+zjOVMrnx3MVO3l9C1qgCoJvSoFl8rmix5NICrHTmO1c3Iu2yj30ID vFOdMRZWJ3QdG6YlJLbkKeArvRsz1E57xPwl6YYzcPeNX/fTshBBBZyUtdh0TJCM pw/x2mI50qw9NRg0iJyGGEGZ/tkRr/jZdmmwXgu8ZI4J2hKskMS6oBitY0W3NDKi cgyOwfbeOTsWQC/C+WHxMSDWE0FJ7n4celzLhycenuejTvqcDpg3taQMlafMzJHA 8BuINoVpkbKQmuU/xS2E1mEW9QNZFoJYx7og2j27YJjR2KQcg9JyEF07DokVNj1E /q/6lb13CuuZ0r2idgE7RqapQE9nke0cK6AnPAlKT42ZNpsvXb1Z3fxNIpPVd4ZS APgh2raakjIpcwlhWBK0cyYwN8Q9D8T70RBcYbDRhjOshC0Zn8DPJ8F9vnZ7x7pc 5YY3hbJDvlRLOc7Hbxwa3bPk2ERJTDn2pJ8xZPdMZth6HZsEyBoNGzRCPgSpaYBL cceqn2hI+tJV+K3m6mRD =sCzl -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/4e441420.5050...@toell.net
Re: libwww0 dependency problem on new architecture
On Sunday 28 August 2005 00:31, Lennert Buytenhek wrote: On Sat, Aug 27, 2005 at 10:15:36PM +0200, Lennert Buytenhek wrote: While trying to bootstrap debian sarge for a new architecture*, I'm having some problems while building the w3c-libwww package. In short, the regular sarge arm libwww0 package has the following control directives: Depends: libc6 (= 2.3.2-1), libgcc1 (= 1:3.3.1-1), zlib1g (= 1:1.1.4) Conflicts: libwww-ssl0 But the version that I get when I do dpkg-buildpackage ends up with the following directives: Depends: libc6 (= 2.3.2.ds1-21), libwww-ssl0 (= 5.4.0), zlib1g (= 1:1.2.1) Conflicts: libwww-ssl0 For one, my package doesn't depend on libgcc1 (why?), but the more serious problem is that when I build the package, it both depends on and conflicts with libwww-ssl0! Actually, if I try to rebuild sarge w3c-libwww on a clean sarge install, I also get the depends+conflicts overlap: Depends: libc6 (= 2.3.2.ds1-21), libwww-ssl0 (= 5.4.0), zlib1g (= 1:1.2.1) Conflicts: libwww-ssl0 Strange, w3c-libwww-5.4.0 builds here just fine, no depends+conflict overlaps. Package: libwww0 Version: 5.4.0-9 Section: libs Priority: optional Architecture: i386 Depends: libc6 (= 2.3.2.ds1-21), zlib1g (= 1:1.2.1) Conflicts: libwww-ssl0 ... Same for other produced debs... libtool --version ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian: 49 $ Is this a package bug? I'm not sure. Did you check having all of these: dpkg-checkbuilddeps debian/control Perhaps some of Build-Depends are not enough strictly declared but should be. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libwww0 dependency problem on new architecture
Hi!
I'm not sure whether this is the right mailing list to ask this question
-- if it's not, I apologise, and would appreciate a pointer to a better
place to ask this question. Thanks.
While trying to bootstrap debian sarge for a new architecture*, I'm
having some problems while building the w3c-libwww package.
In short, the regular sarge arm libwww0 package has the following
control directives:
Depends: libc6 (= 2.3.2-1), libgcc1 (= 1:3.3.1-1), zlib1g (= 1:1.1.4)
Conflicts: libwww-ssl0
But the version that I get when I do dpkg-buildpackage ends up with
the following directives:
Depends: libc6 (= 2.3.2.ds1-21), libwww-ssl0 (= 5.4.0), zlib1g (=
1:1.2.1)
Conflicts: libwww-ssl0
For one, my package doesn't depend on libgcc1 (why?), but the more
serious problem is that when I build the package, it both depends on
and conflicts with libwww-ssl0!
I've tried a number of things but am kind of lost as to what could
be causing this. Can anyone here give me a hand with this? Is it just
a matter of me having different versions of packages installed as the
arm buildd that originally built the sarge libwww0 package, or is something
else going on?
thanks,
Lennert
* I'm building sarge for big-endian ARM systems ('armeb'), see
http://sukurys.wantstofly.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libwww0 dependency problem on new architecture
On Sat, Aug 27, 2005 at 10:15:36PM +0200, Lennert Buytenhek wrote: While trying to bootstrap debian sarge for a new architecture*, I'm having some problems while building the w3c-libwww package. In short, the regular sarge arm libwww0 package has the following control directives: Depends: libc6 (= 2.3.2-1), libgcc1 (= 1:3.3.1-1), zlib1g (= 1:1.1.4) Conflicts: libwww-ssl0 But the version that I get when I do dpkg-buildpackage ends up with the following directives: Depends: libc6 (= 2.3.2.ds1-21), libwww-ssl0 (= 5.4.0), zlib1g (= 1:1.2.1) Conflicts: libwww-ssl0 For one, my package doesn't depend on libgcc1 (why?), but the more serious problem is that when I build the package, it both depends on and conflicts with libwww-ssl0! Actually, if I try to rebuild sarge w3c-libwww on a clean sarge install, I also get the depends+conflicts overlap: Depends: libc6 (= 2.3.2.ds1-21), libwww-ssl0 (= 5.4.0), zlib1g (= 1:1.2.1) Conflicts: libwww-ssl0 Is this a package bug? cheers, Lennert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libwww0 dependency problem on new architecture
On Sat, Aug 27, 2005 at 11:31:40PM +0200, Lennert Buytenhek wrote: Actually, if I try to rebuild sarge w3c-libwww on a clean sarge install, I also get the depends+conflicts overlap: I just tried and encountered serious problems building the libwww packages. It seems that something about the build process has changed. Also, libtool is giving me trouble again... :-( I'll investigate - feel free to file a FTBFS bug against the package. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependency problem
Hi Silke, My idea to solve the above problem has been to explicitly require at least the same version of libgdal1 that python-gdal has. So I put the following lines into debian/control: That's the wrong way to do it. Just think someone else is using your library (like qgis) and he will run into the exact same problem as you with python-gdal. To solve this, Debian uses shlibs files to specify the minimum required version of a library for a program which is linked against your current package. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps In your case, you would probably use this line in your rules: dh_makeshlibs -V'libgdal1 (= 1.2.1)' Thanks, Jochen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependency problem
On Sun, Aug 08, 2004 at 09:06:44AM +0200, Jochen Friedrich wrote: Hi Silke, My idea to solve the above problem has been to explicitly require at least the same version of libgdal1 that python-gdal has. So I put the following lines into debian/control: That's the wrong way to do it. Just think someone else is using your library (like qgis) and he will run into the exact same problem as you with python-gdal. To solve this, Debian uses shlibs files to specify the minimum required version of a library for a program which is linked against your current package. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps In your case, you would probably use this line in your rules: dh_makeshlibs -V'libgdal1 (= 1.2.1)' Many thanks! This has been exactly what I have been looking for. Silke -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIShttp://freegis.org/ pgpPeRTfEtxVh.pgp Description: PGP signature
Re: Dependency problem
Hi Silke, My idea to solve the above problem has been to explicitly require at least the same version of libgdal1 that python-gdal has. So I put the following lines into debian/control: That's the wrong way to do it. Just think someone else is using your library (like qgis) and he will run into the exact same problem as you with python-gdal. To solve this, Debian uses shlibs files to specify the minimum required version of a library for a program which is linked against your current package. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps In your case, you would probably use this line in your rules: dh_makeshlibs -V'libgdal1 (= 1.2.1)' Thanks, Jochen
Re: Dependency problem
On Sun, Aug 08, 2004 at 09:06:44AM +0200, Jochen Friedrich wrote: Hi Silke, My idea to solve the above problem has been to explicitly require at least the same version of libgdal1 that python-gdal has. So I put the following lines into debian/control: That's the wrong way to do it. Just think someone else is using your library (like qgis) and he will run into the exact same problem as you with python-gdal. To solve this, Debian uses shlibs files to specify the minimum required version of a library for a program which is linked against your current package. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps In your case, you would probably use this line in your rules: dh_makeshlibs -V'libgdal1 (= 1.2.1)' Many thanks! This has been exactly what I have been looking for. Silke -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIShttp://freegis.org/ pgprCjKaQpQH5.pgp Description: PGP signature
Dependency problem
Hallo!
I am the sponsored maintainer of gdal. Since I have some open bugs I
am preparing a new package, but I have a problem where I don't
know what to insert in the dependency field of a package.
Please look at bug number 25344 [1]:
python-gdal contains the python bindings for libgdal1 and hence is
dependent on libgdal1. There has been a CVS version of gdal in the
debian archives in debian for a few months until gdal 1.2.0 has been
released. gdal 1.2.0 contains a few more functions than the older
cvs-version and so it is not possible to load the gdal python
bindings of 1.2.0 when libgdal1+cvs03 is on the system.
My idea to solve the above problem has been to explicitly require at
least the same version of libgdal1 that python-gdal has. So I put
the following lines into debian/control:
Section: python
Architecture: any
Depends: ${shlibs:Depends}, ${python:Depends}, libgdal1 (=${Source-Version}),
python-numeric
But now lintian complains:
mimirs gdal 641: lintian -i python-gdal_1.2.1-1_i386.deb
E: python-gdal: package-has-a-duplicate-relation depends: libgdal1,
libgdal1 (= 1.2.1-1)
N:
N: The package seems to declare a relation on another package
which is
N: already implied by other relations it declares, and is
therefore
N: redundant. This is not only sloppy but can break some tools.
N:
I tend to change the above Depends to
Depends: ${shlibs:Depends}, ${python:Depends}, python-numeric
The problem is that this would lead to a situation where people who
have still libgdal1-1.2+cvs03 on their system will have to deal
with a broken python-gdal. Otherwise libgdal1-1.2+cvs03 doesn't
even exist in the debian archives any more.
The other possibility is to rename libgdal1 into libgdal2 but since
libgdal1-1.2+cvs03 did only exist for a very short time this seems
me to be overkill.
I really would like to here the opinion of more experienced
maintainers and DDs.
Many thanks,
Silke
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254344
--
Silke Reimer
Intevation GmbH http://intevation.de/
FreeGIShttp://freegis.org/
pgpiogJJiz2Um.pgp
Description: PGP signature
Dependency problem
Hallo!
I am the sponsored maintainer of gdal. Since I have some open bugs I
am preparing a new package, but I have a problem where I don't
know what to insert in the dependency field of a package.
Please look at bug number 25344 [1]:
python-gdal contains the python bindings for libgdal1 and hence is
dependent on libgdal1. There has been a CVS version of gdal in the
debian archives in debian for a few months until gdal 1.2.0 has been
released. gdal 1.2.0 contains a few more functions than the older
cvs-version and so it is not possible to load the gdal python
bindings of 1.2.0 when libgdal1+cvs03 is on the system.
My idea to solve the above problem has been to explicitly require at
least the same version of libgdal1 that python-gdal has. So I put
the following lines into debian/control:
Section: python
Architecture: any
Depends: ${shlibs:Depends}, ${python:Depends}, libgdal1 (=${Source-Version}),
python-numeric
But now lintian complains:
mimirs gdal 641: lintian -i python-gdal_1.2.1-1_i386.deb
E: python-gdal: package-has-a-duplicate-relation depends: libgdal1,
libgdal1 (= 1.2.1-1)
N:
N: The package seems to declare a relation on another package
which is
N: already implied by other relations it declares, and is
therefore
N: redundant. This is not only sloppy but can break some tools.
N:
I tend to change the above Depends to
Depends: ${shlibs:Depends}, ${python:Depends}, python-numeric
The problem is that this would lead to a situation where people who
have still libgdal1-1.2+cvs03 on their system will have to deal
with a broken python-gdal. Otherwise libgdal1-1.2+cvs03 doesn't
even exist in the debian archives any more.
The other possibility is to rename libgdal1 into libgdal2 but since
libgdal1-1.2+cvs03 did only exist for a very short time this seems
me to be overkill.
I really would like to here the opinion of more experienced
maintainers and DDs.
Many thanks,
Silke
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254344
--
Silke Reimer
Intevation GmbH http://intevation.de/
FreeGIShttp://freegis.org/
pgpzRHGkV8DEr.pgp
Description: PGP signature
Re: binutils-dev dependency problem...
Adam Moreover, binutils-dev description says: Adam Note that building Debian packages which depend on the shared Adam libbfd is Not Allowed. Adam So what should I do to fix the problems? Link whole package Adam staticaly?? Thanks in advance for your help... This is actually quite interesting. Not allowed by whom? Is this in the policy anywhere? -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 EngSoc adopts market economy: cheap is wasteful, efficient is expensive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
binutils-dev dependency problem...
Hi, I have a package 'fenris', which depends on libbfd. The problem is it depends on the EXACT version of the library: [EMAIL PROTECTED]:~$ ldd which fenris libbfd-2.12.90.0.1.so = /usr/lib/libbfd-2.12.90.0.1.so (0x40049000) ... and my package has to depend on exactly the same version of binutils-dev (containing libbfd) - which causes problems when new version enters the archive: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=158246repeatmerged=yes Moreover, binutils-dev description says: Note that building Debian packages which depend on the shared libbfd is Not Allowed. So what should I do to fix the problems? Link whole package staticaly?? Thanks in advance for your help... Regards [EMAIL PROTECTED] -- _.|._ |_ _.: Adam Byrtek, [EMAIL PROTECTED] (_|||_)| |(_|: gg 1802819, pgp 0xB25952C0 |
Re: binutils-dev dependency problem...
Adam Moreover, binutils-dev description says: Adam Note that building Debian packages which depend on the shared Adam libbfd is Not Allowed. Adam So what should I do to fix the problems? Link whole package Adam staticaly?? Thanks in advance for your help... This is actually quite interesting. Not allowed by whom? Is this in the policy anywhere? -- Ian Zimmerman, Oakland, California, U.S.A. GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087 EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
library dependency problem
I have a problem with the slang library. The current version is slang1_1.2.2 I began to package the new version 1.3.8. I installed it on my own system to test and everything went fine. However when I upgraded to the latest potato anything depending on slang1 broke because they all had depends like: slang1 ( 1.3), slang1 ( 1.2.2-0) When I took over the slang1 package I failed to notice the shlibs that defined the above. The problem is that version 1.3.x is compatible with 1.2. This leaves me with a number of options: 1. Just create a new package slang1.3_1.3.8 The problem with this is that users will have slang1 and slang1.3 installed on their system. And when 1.4 comes along (which should also be compatible) I will have to make a slang1.4_1.4 package, and so on. By 1.8 users will have 6 slang packages, that could be all compatible. 2. Continue to call it slang1 and upload the new version. It will conflict with the old one, replace it and then break the dependencies of everything that depends on slang. (note: only breaks the dependencies, the packages would otherwise run fine) Thereby forcing everyone else to upgrade their (slang dependent) packages. 3. Create some sort of dummy package that the new package depends on and it provides 1.2.9 or something like that. (seems like a bad idea in general) 4. ? Is there something I'm missing, is there a way out of this mess? -- Jim Mintha Email: [EMAIL PROTECTED] System Administrator Work: +31 20 525-4919 Informatiseringscentrum Home: +31 20 662-3892 University of Amsterdam Debian GNU/Linux: [EMAIL PROTECTED] _There are always Possibilities_ http://jim.ultralinux.org
Re: library dependency problem
On Mon, Jul 26, 1999 at 02:19:33AM +0200, Jim Mintha wrote: I have a problem with the slang library. The current version is slang1_1.2.2 I began to package the new version 1.3.8. I installed it on my own system to test and everything went fine. However when I upgraded to the latest potato anything depending on slang1 broke because they all had depends like: slang1 ( 1.3), slang1 ( 1.2.2-0) When I took over the slang1 package I failed to notice the shlibs that defined the above. The problem is that version 1.3.x is compatible with 1.2. Hm. This is bad. :( This leaves me with a number of options: 1. Just create a new package slang1.3_1.3.8 Just one note - if you're changing the name, you ought to call it libslangsoname as per Policy. The problem with this is that users will have slang1 and slang1.3 installed on their system. And when 1.4 comes along (which should also be compatible) I will have to make a slang1.4_1.4 package, and so on. By 1.8 users will have 6 slang packages, that could be all compatible. This option reminds me on the way GTK+ libraries are named... and it sucks. Don't do it if there's any other solution. 2. Continue to call it slang1 and upload the new version. It will conflict with the old one, replace it and then break the dependencies of everything that depends on slang. (note: only breaks the dependencies, the packages would otherwise run fine) Thereby forcing everyone else to upgrade their (slang dependent) packages. If it is a good thing to recompile against the new library version, and considering the fact that number of source packages that depend on slang currently is about 30, this is something that Debian can do for potato... 3. Create some sort of dummy package that the new package depends on and it provides 1.2.9 or something like that. (seems like a bad idea in general) This is possible, create slang1 1.2.999dummy-1 package that depends on libslang1. And then in libslang1's control file set this: Conflicts: slang1 ( 1.2.999dummy) Replaces: slang1 ( 1.2.999dummy) Provides: slang1 (the last one is futile, but just for the sake of it) It might just work :) And nothing would *need* to be recompiled. The only bad thing about dummy packages in general is that they are cruft after some time... -- enJoy -*/\*- don't even try to pronounce my first name
Re: library dependency problem
On Mon, Jul 26, 1999 at 02:19:33AM +0200, Jim Mintha wrote: slang1 ( 1.3), slang1 ( 1.2.2-0) When I took over the slang1 package I failed to notice the shlibs that defined the above. The problem is that version 1.3.x is compatible with 1.2. This leaves me with a number of options: Hmm, looks like I shouldn't have not filed that wishlist bug on the theory that maintainer knew what they were doing better then I. 2. Continue to call it slang1 and upload the new version. It will conflict with the old one, replace it and then break the dependencies of everything that depends on slang. (note: only breaks the dependencies, the packages would otherwise run fine) Thereby forcing everyone else to upgrade their (slang dependent) packages. This is, IMHO, the best option. The jed maintainer has been waiting on you to upgrade so he can package the latest upstream, I know, and all that would be required is a simple rebuild. I'd say package away, and file Important (possibly even Grave, since the package won't install) bugs against everything depending on libslang1 to let the maintainers know to rebuild. Is it possible to Provide: libslang (1.2.99)? (Warning: Idle speculation) -=- James Mastros -- Caveat Emptator: I am not a Developer. (But I use libslang-using binaries, if that counts for anything.)
help: dependency problem
Hello List !
I can't get rid of my dependency problems. (MySQL has more conflicts than
any soap opera :-)) Maybe someone can give me a hint !
Here is the current situation:
(src: mysql - non-free)
mysql server + docs
mysql-clientclient + all libraries
mysql-devel header
(src: mysql-freebits - main)
mysql-base client
mysql-doc doc
mysql-dev header + all libraries
This can't go because a shared lib on which the client depend has nothing
to do in -dev; the structure is not clear to the user; soon there will be
two complete new upstream versions: an old GPL'ed and the recent (in
non-free). So I made a new scheme:
(src: mysql - non-free)
mysql-server
mysql-client
mysql-doc
mysql-dev
mysql-bench (never packaged before)
(src: mysql-gpl - main)
mysql-gpl-server(released to GPL at mid-june)
mysql-gpl-client
mysql-gpl-doc
mysql-gpl-dev
mysql-gpl-bench
But... How to make the dependencies ? The current situation is that
whenever I change from the GPL'ed to the non-free I have to do a
dpkg -i --auto-deconfigure *-gpl-*.deb
TWICE before it really works.
If someone is willing to help me out, I will post him every control file I
have. I do not post it to the list because this mail is already long
enough.
Thousand thanks in advance !
read you,
-christian-
{{{Uaaah! Why the hell did I intend to package this monster...}}}
--
Linux - the choice of the GNU generation. Join the Debian Project
http://www.debian.org
Christian Hammers * Oberer Heidweg 35 * D-52477 Alsdorf * Tel: 02404-25624
50 3C 52 26 3E 52 E7 20 D2 A1 F5 16 C4 C9 D4 D3 1024/925BCB55 1997/11/01
