In the section TIMTOWTDI I suggest "apt-cache showpkg".
Eric
On 10 May 2014 03:35:02 CEST, Fernando Toledo wrote:
>El 06/05/14 03:35, Jörg Frings-Fürst escribió:
>> Hi,
>>
>> is there a way to determine in how many and in which packages a
>> package is added as a dependency?
>>
>>
>> Jörg
>>
El 06/05/14 03:35, Jörg Frings-Fürst escribió:
> Hi,
>
> is there a way to determine in how many and in which packages a
> package is added as a dependency?
>
>
> Jörg
>
>
maybe using python-debian ?
https://upsilon.cc/~zack/blog/posts/2008/07/python-debian_w_dependency_parsing/
https://gith
On Mon, May 5, 2014 at 11:35 PM, Jörg Frings-Fürst
wrote:
> Hi,
>
> is there a way to determine in how many and in which packages a package
> is added as a dependency?
reverse-depends (from ubuntu-dev-tools), build-rdeps (from
devscripts), or "dak rm -nR -s unstable -b " on coccia.d.o.
Regards,
On Sat, Oct 15, 2011 at 14:31, Игорь Пашев wrote:
> Ok, multi-arch is good.
> Can anyone help me:
> for now i386 and amd64 libs are built from the same source
> at the same time - I can't change this way. I'd like to pack these libs.
> I'm sure I'm far from the truth :-)
Do yourself a favor: Forg
Ok, multi-arch is good.
Can anyone help me:
for now i386 and amd64 libs are built from the same source
at the same time - I can't change this way. I'd like to pack these libs.
I'm sure I'm far from the truth :-)
Please, correct me:
debian/control:
Source: ...
...
Package: libfoo
Section: libs
On Sat, Oct 15, 2011 at 4:21 AM, Igor Pashev wrote:
> I'm building a package with:
>
> 64-bits app (foo),
> 64-bits lib (libfoo) and
> 32-bits lib (lib32foo).
Please use multiarch instead of doing that.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-
Le 07/10/11 10:16, Ole Streicher a écrit :
> Hi,
>
> in a library that I want to package for Debian, there is a runtime check
> that another library has the same version number as at compile time:
>
> ---8<-
> float cfitsio_version;
-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
[...]
> >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
On 11/08/11 18:23, Jakub Wilk wrote:
* Torquil Macdonald Sørensen , 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 | p
* Torquil Macdonald Sørensen , 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 |
Hi,
The bzip2 code from Ant has been factored out as a separate library
recently (Commons Compress). You may try to switch to it.
http://commons.apache.org/compress
http://packages.debian.org/squeeze/libcommons-compress-java
Emmanuel Bourg
Giovanni Mascellani a écrit :
Hi all.
A Java pac
Giovanni Mascellani wrote:
> Hi all.
>
> A Java package I'm working on (osmosis) uses some bzip2 embedded code
> copy (less than 10 classes) from the ant project (classes
> org.apache.tools.bzip2.*): if I want to avoid embedded code copies, I
> need to make osmosis depend on ant, forcing the user
Hello,
> > The source of the EPS lib is contained in the UMLet release
>
> Then it's not an external dependency, you have a fork. A fork that is -
> and therefore will remain - GPL. What you may miss out on are updates,
> that's all.
It was shipped with UMLet only for convenience. But since jib
On Tue, 05 Dec 2006 21:33:58 +0100
Benjamin Mesing <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am in the process of packaging UMLet [1] which depends on the external
> library EPS Graphics2d [2]. Apparantly that libray used to be available
> under GPL but is now distributed on a commercial basis.
h
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 d
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 d
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
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
On Wed, Jan 07, 2004 at 01:52:11PM -0700, Al Stone wrote:
> OTOH, by not making it a "Depends:", I could end
> up with a situation where installing oprofile or
> prospect would work, but the tools themselves would
> not because the kernel module is missing.
>
> The upstream author for prospect rea
On Wed, Jan 07, 2004 at 01:52:11PM -0700, Al Stone wrote:
> OTOH, by not making it a "Depends:", I could end
> up with a situation where installing oprofile or
> prospect would work, but the tools themselves would
> not because the kernel module is missing.
>
> The upstream author for prospect rea
Al Stone <[EMAIL PROTECTED]> writes:
> I've got packages I'm maintaining -- oprofile and prospect -- that
> both need a particular kernel module to work.
>
> Right now, these packages only "Recommend:" the kernel module (in
> this case, oprofile-module0.6.1).
>
> I did not want to make it a "Depen
Al Stone <[EMAIL PROTECTED]> writes:
> I've got packages I'm maintaining -- oprofile and prospect -- that
> both need a particular kernel module to work.
>
> Right now, these packages only "Recommend:" the kernel module (in
> this case, oprofile-module0.6.1).
>
> I did not want to make it a "Depen
* Al Stone <[EMAIL PROTECTED]> [040107 21:52]:
> Right now, these packages only "Recommend:" the
> kernel module (in this case, oprofile-module0.6.1).
[...]
> OTOH, by not making it a "Depends:", I could end
> up with a situation where installing oprofile or
> prospect would work, but the tools the
* Al Stone <[EMAIL PROTECTED]> [040107 21:52]:
> Right now, these packages only "Recommend:" the
> kernel module (in this case, oprofile-module0.6.1).
[...]
> OTOH, by not making it a "Depends:", I could end
> up with a situation where installing oprofile or
> prospect would work, but the tools the
Al Stone wrote:
> The packages themselves are tools that run in
> user-space, collecting and analyzing performance
> data from a kernel module that must be loaded.
Why not create a shell script wrapper around the tool(s) that checks
that the module is loaded, or tries to load it if missing? If th
Al Stone wrote:
> The packages themselves are tools that run in
> user-space, collecting and analyzing performance
> data from a kernel module that must be loaded.
Why not create a shell script wrapper around the tool(s) that checks
that the module is loaded, or tries to load it if missing? If th
On Thu, Oct 23, 2003 at 01:26:10AM +0200, Magosányi Árpád wrote:
> Zorp depends on libssl.
> DSA-393-1 says that libssl 0.9.7c-1 should be okay.
> The shlibs file of libssl0.9.7 contains an unversioned dependency,
> and because of that, zorp's dependency is also not versioned.
> Questions:
> -Sh
On Thu, Oct 23, 2003 at 01:26:10AM +0200, Magosányi Árpád wrote:
> Zorp depends on libssl.
> DSA-393-1 says that libssl 0.9.7c-1 should be okay.
> The shlibs file of libssl0.9.7 contains an unversioned dependency,
> and because of that, zorp's dependency is also not versioned.
> Questions:
> -Sh
On Wed, 21 Aug 2002 14:53:54 -0700
Matt Kraai <[EMAIL PROTECTED]> wrote:
> Here are the solutions I've considered:
>
> * merge them into one source package. This would diverge from
>upstreams distribution model.
There are many examples of putting multiple source packages
in one Debian sou
> Here are the solutions I've considered:
>
> * merge them into one source package. This would diverge from
>upstreams distribution model.
>
> * copy the header file into wordnet-grind. This would have to
>be kept in sync manually.
>
> * build wordnet-dev and force its installation.
> Here are the solutions I've considered:
>
> * merge them into one source package. This would diverge from
>upstreams distribution model.
>
> * copy the header file into wordnet-grind. This would have to
>be kept in sync manually.
>
> * build wordnet-dev and force its installation
On Mon, Jan 14, 2002 at 09:46:03AM -0500, Adam C Powell IV wrote:
> In a post to this list about a year ago, someone suggested that complex
> dependencies such as "(A & B) | C" be handled with: "A | C, B | C". Now
> this generates a lintian error:
>
> E: petsc2.1.1-dev: package-has-a-duplicate-
On Mon, Jan 14, 2002 at 09:46:03AM -0500, Adam C Powell IV wrote:
> In a post to this list about a year ago, someone suggested that complex
> dependencies such as "(A & B) | C" be handled with: "A | C, B | C". Now
> this generates a lintian error:
>
> E: petsc2.1.1-dev: package-has-a-duplicate
On Fri, Feb 09, 2001 at 12:06:14PM +0100, Domenico Andreoli wrote:
> > Depends: curl (= 7.4.2-2) | curl (>= 7.5-1),
> > libcurl0-ssl (= 7.4.2-2) | curl (>= 7.5-1),
> > curl (= 7.4.2-2) | libcurl1-ssl (>= 7.5-1),
> > libcurl0-ssl (= 7.4.2-2) | libcurl1-ssl (>= 7.5-1)
> >
On Fri, Feb 09, 2001 at 12:06:14PM +0100, Domenico Andreoli wrote:
> > Depends: curl (= 7.4.2-2) | curl (>= 7.5-1),
> > libcurl0-ssl (= 7.4.2-2) | curl (>= 7.5-1),
> > curl (= 7.4.2-2) | libcurl1-ssl (>= 7.5-1),
> > libcurl0-ssl (= 7.4.2-2) | libcurl1-ssl (>= 7.5-1)
> >
On Thu, Feb 08, 2001 at 09:07:11AM -0600, Richard Braakman wrote:
> On Thu, Feb 08, 2001 at 03:39:33PM +0100, Domenico Andreoli wrote:
> > the question is which dependencies should curl-ssl have?
> >
> > i'm thinking something like:
> > Conflicts: curl(<7.4.2-2)
> > Depends: curl(>=7.4.2-2), l
On Thu, Feb 08, 2001 at 09:07:11AM -0600, Richard Braakman wrote:
> On Thu, Feb 08, 2001 at 03:39:33PM +0100, Domenico Andreoli wrote:
> > the question is which dependencies should curl-ssl have?
> >
> > i'm thinking something like:
> > Conflicts: curl(<7.4.2-2)
> > Depends: curl(>=7.4.2-2),
On Thu, Feb 08, 2001 at 03:39:33PM +0100, Domenico Andreoli wrote:
> the question is which dependencies should curl-ssl have?
>
> i'm thinking something like:
> Conflicts: curl(<7.4.2-2)
> Depends: curl(>=7.4.2-2), libcurl0-ssl(=7.4.2-2) | libcurl1-ssl(>=7.5-1)
If you Depend on curl >= 7.4.2-
On Thu, Feb 08, 2001 at 03:39:33PM +0100, Domenico Andreoli wrote:
> the question is which dependencies should curl-ssl have?
>
> i'm thinking something like:
> Conflicts: curl(<7.4.2-2)
> Depends: curl(>=7.4.2-2), libcurl0-ssl(=7.4.2-2) | libcurl1-ssl(>=7.5-1)
If you Depend on curl >= 7.4.2
Will Lowe:
> You could put each binary in a seperate package, and then each package
> could have the right dependencies.
I wonder if it would really be worth it, since the documentation and sample
scripts (which I would need to include in both packages) are as big as the
actual binaries. (Okay,
> The current package also depends on mail-transport-agent, which is needed
> (by both versions) to send mail. But, if you don't use the mail feature, it
> is not needed. Should I really have this as a dependency?
>
> Should I change them both to Recommends, or even Suggests?
You could put each b
On Fri, May 12, 2000 at 01:40:26PM +0200, Tom Cato Amundsen wrote:
> I am programming and packaging solfege,a python program for GNOME (in
> incoming rsn).
>
> Currently is depends on python-gnome (>=1.0.50) and python-gtk (0.6.6),
> since this versions worked just fine some weeks (months???) ago.
On Fri, May 12, 2000 at 01:40:26PM +0200, Tom Cato Amundsen wrote:
> Should I keep the Depends: line as short as possible, and only depend
> on python-gnome, since is it depends on python-gtk? This seems ok to
> me so I'll to it if nobody objects.
There is no benefit to keeping the Depends field s
On Fri, 12 May 2000, Tom Cato Amundsen wrote:
> I am programming and packaging solfege,a python program for GNOME (in
> incoming rsn).
>
> Currently is depends on python-gnome (>=1.0.50) and python-gtk (0.6.6),
> since this versions worked just fine some weeks (months???) ago.
>
> Should I keep
45 matches
Mail list logo
