gt; I thought ldconfig automatically creates the necessary symbolic links
> provided the postinst, postrm scripts invoke ldconfig properly.
Please see Policy section 8.1.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
icy doesn't care how you get the symlink *into* the package, if that's
what you're asking; it only requires that the symlink provided by the
package be the same one that ldconfig *would* create.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
an-webapps is web
*application* packages, not "packages implemented in PHP or providing PHP
bindings that may or may not be used by web application packages".
debian-webapps is absolutely not the right forum for discussing PHP/PEAR
library policy. AFAIK, none of the comaintainers of the act
On Fri, Jul 29, 2005 at 07:54:22PM +0100, Neil McGovern wrote:
> On Fri, Jul 29, 2005 at 10:51:47AM -0700, Steve Langasek wrote:
> > On Fri, Jul 29, 2005 at 05:58:13PM +0100, Neil McGovern wrote:
> > > On Thu, Jul 28, 2005 at 06:22:43PM -0300, Jose Carlos do Nascimento wrote:
>
m before with the ImageMagick ABI
changing and causing precisely this error for some other package. If the
ABI has changed, the library package name *must* be changed; if that's so,
then this bug should be cloned and reassigned to libmagick6.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
data exclusively
> used by the application" -FHS 4.4-) should be suppressed.
Such modules shouldn't actually have SONAMEs at all; perhaps fixing the
build to not include an SONAME for something that isn't a shared library
would make this warning go away.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
On Sat, Aug 06, 2005 at 08:52:24PM +0200, Mattia Dongili wrote:
> On Sat, Aug 06, 2005 at 09:34:37AM -0700, Steve Langasek wrote:
> > On Sat, Aug 06, 2005 at 02:28:32PM +0200, Mattia Dongili wrote:
> > > On Sat, Aug 06, 2005 at 01:01:12PM +0200, Ghe Rivero wrote:
> > >
blem with AC_PATH_X is that it checks for a particular function which
is provided by the Xt library, not by libX11. The fix for this is that
AC_PATH_X takes optional arguments, telling it to check a different
function/lib:
AC_PATH_X([X11], [X11/Xlib.h], [XOpenDisplay(NULL)])
That should be eno
rchive, that makes it harder for NMUers or passing developers
to see what's going on in your package.
The autotools-dev README.Debian is a good guide to these issues.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Fri, Aug 12, 2005 at 12:04:31PM +0200, Bas Wijnen wrote:
> On Fri, Aug 12, 2005 at 02:12:57AM -0700, Steve Langasek wrote:
> > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
> > > I have some packages which use autotools. I thought it would be good to
> &
things and then it is not
> harder to see, what is going on.
No, it just makes it hard to examine the differences between two versions
using debdiff, rather than making it hard to look at the diff for a single
version.
--
Steve Langasek Give me a lever long enough a
On Fri, Aug 12, 2005 at 10:59:23AM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 12 Aug 2005, Steve Langasek wrote:
> > On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote:
> > > > Aside from wasting (a little)
> > > > space in the archive, t
On Fri, Aug 12, 2005 at 02:01:13PM -0400, Justin Pryzby wrote:
> or, if it is on a "testing" box, debian-testing.
Please, no. The debian-testing list exists for identifying upgrade issues
for the next stable release -- this is not that.
--
Steve Langasek Give me
On Sat, Aug 13, 2005 at 01:13:11PM +0200, Armin Berres wrote:
> Steve Langasek wrote:
> > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote:
> > If you rerun autoconf/automake/libtool at package build-time, when you don't
> > need to, what you get are large di
m: binary-without-manpage qterm
> $ linda qterm_0.4.0pre2.ds.3-2_i386.changes
> E: qterm; No manual page for binary qterm.
> W: qterm; The command /usr/bin/qterm"
> icon32x32="/usr/share/pixmaps/qterm_32x32.xpm"
> icon16x16="/usr/share/pixmaps/qterm_16x16.xpm li
If
that's the case, what happens if a user copies their own libc.so.6 into
the chroot and tells the dynamic linker to use *that*?
Including a full copy of glibc in this package also means that it will
be affected by the same security holes that affect the main glibc
package, and yo
ges like lilo, mailx,
> > mount, netpbm use it, too.
> For future ref for anyone:
> Yup, it's the BSD 3 clause licence, which is fine.
> The 4 clause isn't, as it has teh 'advertising' clause in it.
Uh, no, 4 clause BSD *is* allowed in main.
--
Steve Langasek
. Unfortunately, there are a number of upstreams
(e.g., GNOME) that are unlikely to be willing to make such a switch this
late in the game.
The current upstream for pkg-config is a Debian developer, even, but
he's somewhat constrained by the loopy ideas that others in the
community have
On Sat, Sep 03, 2005 at 01:47:01PM +1000, skaller wrote:
> On Fri, 2005-09-02 at 20:09 -0700, Steve Langasek wrote:
> > On Sat, Sep 03, 2005 at 12:46:31PM +1000, skaller wrote:
> > > Does Debian have a policy on use of pkg-config?
> > > On my Ubuntu systems there are s
On Sat, Sep 03, 2005 at 11:54:55AM +0100, Neil Williams wrote:
> On Saturday 03 September 2005 6:11 am, Steve Langasek wrote:
> > No, it's not. The .pc names are set by upstream and we should not
> > diverge from them, and the package names are governed by Debian policy
>
amic, and I never set up anything about this, I don't
> know what to do about that
What does objdump -p $path/usr/bin/kshutdown | grep NEEDED show?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can
On Sun, Sep 04, 2005 at 12:13:47AM +0200, Romain Beauxis wrote:
> Le Dimanche 4 Septembre 2005 00:12, Romain Beauxis a écrit :
> > Le Samedi 3 Septembre 2005 22:56, Steve Langasek a écrit :
> > > What does objdump -p $path/usr/bin/kshutdown | grep NEEDED show?
> >
> >
uld use exactly
> what objdump show..
ldd traverses dependencies and reports all of the libraries that would
be loaded into memory by ld.
On Sun, Sep 04, 2005 at 12:59:06AM +0200, Romain Beauxis wrote:
> Le Dimanche 4 Septembre 2005 00:45, Steve Langasek a écrit :
> > - your build
On Sun, Sep 04, 2005 at 01:04:40AM +1000, skaller wrote:
> On Sat, 2005-09-03 at 04:19 -0700, Steve Langasek wrote:
> > At the present time and given the current state of the software I
> > believe it is not in Debian's best interest that you ship a .pc file *at
> > al
On Sun, Sep 04, 2005 at 08:52:53AM +0100, Neil Williams wrote:
> On Sunday 04 September 2005 7:13 am, Steve Langasek wrote:
> > pkg-config and libtool are both tools designed to facilitate portability
> > to platforms which have inferior linkers, and in the process they
> >
27;Debian policy says to put libraries in /usr/lib'
> which means in theory you don't need any -L switches (more or less),
> however some packages don't conform to this policy, so you may still
> need -L switches: that's what I meant .
On Sun, Sep 04, 2005 at 11:22:33PM +1000, skaller wrote:
> On Sun, 2005-09-04 at 04:08 -0700, Steve Langasek wrote:
> > On Sun, Sep 04, 2005 at 08:06:07PM +1000, skaller wrote:
> > The second part,
> > MIT_KRB5_17 {
> > global:
> > *;
> > }
> &g
On Sun, Sep 04, 2005 at 03:37:52PM +0200, Romain Beauxis wrote:
> Le Dimanche 4 Septembre 2005 06:52, Steve Langasek a écrit :
> > I've looked over the package update, and for the most part it looks ok,
> > but the new Portuguese translation that upstream included is quite b
fraid I have to disagree; I understand this to be a major
difference between an RFA and an O, in that a maintainer submitting an
RFA reserves the right to choose a successor. I'm surprised to hear
that there's documentation which suggests otherwise.
--
Steve Langasek
nding on build-essential is certainly wrong.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
e do that can't already be done with
pam_listfile or pam_group?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.
On Wed, Sep 14, 2005 at 06:04:29PM +0100, Sam Morris wrote:
> Steve Langasek wrote:
> >>retitle 262121 ITP: libpam-require -- PAM module to allow and/or deny
> >>particular users and/or groups
> >>owner 262121 !
> >>thanks
> >>I want to become th
can't do the right thing
before the theme is unpacked, then the config script should exit without
attempting to set any debconf variables.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[
inst script dependencies must
be enforced with pre-dependencies, and config scripts must be resilient
against being called before dependencies are installed because there is no
package relationship that can be declared for config scripts.
--
Steve Langasek Give me a lever long en
part.
But please don't follow up to spam.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.as
re expects to find them.
Best of all, fix the software to not look for its configuration outside of
/etc, which is actually what the FHS requires.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move
b(1)
Every file under /etc is automatically marked as a conffile *when using
debhelper*. While most packagers are using debhelper these days, please be
clear about this, as it is an optional helper package and not mandated by
policy.
--
Steve Langasek Give me a lever long enough
t possible, because of a circular
conflict/pre-depends in some essential packages that requires upgrading to
sarge before upgrading to etch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can
case of a bug in the current version (or in
exceptional cases, such as a kernel or libc needing a particular compiler
version because the package abuses the compiler).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and
change from 3.4 to 4.0.
The ABI change is between 3.3 and 3.4, not 3.4 and 4.0.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
karound for this is to call db_stop at the end of your
postinst to force-detach the debconf daemon.
- --
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
he alternatives is sufficient.
> Thanks for you knowledge in this.
awk is "virtually essential": it can't be Essential: yes because that would
prevent removing mawk in favor of gawk, but awk is a dependency of another
essential package to ensure that you can use basic awk functio
riority"
> Priority: required
> Provides: awk
Right conclusion, wrong rationale. A package being Priority: required does
not excuse you from an explicit dependency.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
otherwise) that are not in debian.
True, but uploading a package to contrib instead of main because you haven't
*bothered* to package the deps is pretty lame.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and
> mkdir $_TEMPDIR
> echo $_TEMPDIR
> }
> That is a tag + security race condition between rm and mkdir. You'll
> want to use mktemp -d instead.
It's darn broken, but it's not actually a security hole unless something
else makes bogus assump
t could be caused by some library which it depends on.
> Do you have any advice about it?
> Does anybody experienced a similar breakage?
Probably bug #336114.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it
do this by listing in your Architecture: field in debian/control all of
the architectures for which the package *should* be built. (In this case,
that's definitely the correct course of action because you have a dependency
on a non-free package which is available for a finite, static set of
will the distributed-net binaries for these archs come from?
> I though "Architecture" support something like,
> Architecture: any !alpha !m68k ...
But that's not accurate. You don't support "all archs except for alpha and
m68k", you support &q
nks for a known dead service to be left around
when upgrading to the dummy package. Debhelper is a *helper*, not a
replacement for making sound decisions about creating proper packages.
> What is the usual way to solve this situation?
The usual solution is to not provide such dummy packages at
ting of packages for
those who have a reason to do so. Since your application does not *need*
the new version of the library in order to be built, it helps certain use
cases if you don't use the Build-Depends: field to specify the libraries
that you *want* the package to build with.
Cheers,
-
g into two packages is indeed the best idea here.
Well, you'd think so, except both the C and C++ libraries seem to be
provided by the same library. (I thought this was what he was saying, so I
checked the package in the archive -- one lib file.)
--
Steve Langasek Give me
cy relationship when they
*shouldn't*.
If you depend on newer features than those guaranteed by the debconf-2.0
interface, you will need to depend on the providers of those features
explicitly, *without* an or on "debconf-2.0".
Cheers,
--
Steve Langasek Give me a le
y.
Yes, the best solution available today would be to use
Depends: debconf (>= 1.3.22) | cdebconf (>= ??)
I don't know what minimum version of cdebconf (if any) you should specify to
get support for settitle.
Cheers,
--
Steve Langasek Give me a lever long enoug
easier to contribute, you're much better off
arguing it in terms of the *benefits to the project* (and mitigation of the
risks) than in terms of how it makes a set of possible contributors feel.
And this...
> I run Ubuntu .. I can't even test my own Debian package
> on my own system.
siders "~" to sort before anything, even a null string, so
> you can use e.g. "1.0.0~rc5".
You can't upload such a version to the Debian archive, so the older trick is
not obsolete.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian
he
> package for someone else who wants to work on it to figure out.
For new deployment of patch systems, I would strongly encourage using quilt
instead of dpatch. It has much better handling of patch dependencies than
any of the others, and much more user friendly patch editing/creating
cap
On Mon, Jan 09, 2006 at 10:55:45PM -0800, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > For new deployment of patch systems, I would strongly encourage using
> > quilt instead of dpatch. It has much better handling of patch
> > dependencies than
tch file that you added in -3, as it points to kraptor upstream...
I'll take a look at kraptor as well, since it has a similar RC bug.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world
On Tue, Jan 10, 2006 at 03:19:00AM -0800, Steve Langasek wrote:
> Already uploaded kball, actually; you should've received some email about
> that by now. Looks like bug #345244 wasn't closed in the changelog, though,
> so I'll go close it by hand. Also, you migh
the transitioning library, instead of giving
us transitions that ripple through all the indirect reverse-dependencies.
Just to be clear, relibtoolizing should only need to be a one-time thing.
--
Steve Langasek Give me a lever long enough and a Fr
contents changed".
> How do I add a translation without modifying the configure.in?
You don't. How about just forwarding it upstream instead?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
t's not possible for you to upload --
non-maintainer or otherwise. A DD will have to upload the fix in question.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
On Tue, Jan 17, 2006 at 01:55:27PM +0100, Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 17, 2006 at 01:03:32PM +0100, Bjoern Boschman wrote:
> >> I'd like to close on of the xlibs-dev bugs, but I've never done an NMU
>
nda hard to consider it deprecated while DAK still sets it instead
> of doing a proper job of issuing "notfound" commands to the BTS.
You mean "close" commands...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Wed, Jan 18, 2006 at 10:00:01AM -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 18 Jan 2006, Steve Langasek wrote:
> > On Wed, Jan 18, 2006 at 09:29:35AM -0200, Henrique de Moraes Holschuh wrote:
> > > On Wed, 18 Jan 2006, Thijs Kinkhorst wrote:
> > > >
le feel the need to bundle libltdl in their
sources instead of just telling users to download & install it as a
build-dependency.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL
k to remove it? Or should I better rename it so they
> can use it to convert to a pioneers file by hand? Perhaps that's the best...
> I could make a NEWS message about that as well.
I think the right thing to do here is to simply remove it if we can
determine that it's unm
unstable?
Yes. Since the package is not in unstable, it's not in the source<->binary
map used by bugs.d.o.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
> ask request the binNMU?
Yes.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
On Wed, Feb 15, 2006 at 07:47:11PM +0100, Mattia Dongili wrote:
> On Sun, Feb 12, 2006 at 02:19:08PM -0800, Steve Langasek wrote:
> > On Sun, Feb 12, 2006 at 07:06:00PM +0100, Mattia Dongili wrote:
> > > I need a quick suggestion how to handle libcpufreq{0,-dev} within
rated. is that it? I guess I understand why
> it cannot be run with python2.4 then. I hope someone finds a better solution
> anyway :)
Yeah, we've been working on it... discussion on debian-python over the past
month or two.
--
Steve Langasek Give me a lever lon
a package split sounds like it's needed. Note that this means
splitting the source package, since you can't build binaries for both main
and non-free from the same source. The driver itself sounds like it's
perfectly suitable for main, only the optional firmware wou
e should be -dev. Since the name
> of this library is etl, the name would be etl-dev. Can anyone clarify?
The name "etl-dev" is fine. Prepending "lib" when there's nothing here
named libetl is pointless.
Cheers,
--
Steve Langasek Give me a lever lon
ibraries; anything that
references symbols from other libraries on the system needs to link against
those libraries.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
On Fri, Mar 31, 2006 at 08:41:22AM +0200, Miriam Ruiz wrote:
> --- Steve Langasek <[EMAIL PROTECTED]> escribió:
> > This is discussed in policy 10.2. If your libraries are failing to link
> > when using -z,defs, that's a bug in those libraries; anything that
> &g
gt; Is there a nice solution for this? I guess the right thing should be to tell
> upstream to unify the libraries into one, is there any other solution I can
> handle?
Unifying the libs is the only way to do this cleanly, AFAIK.
Cheers,
--
Steve Langasek Give me a lever
ies a binary links against;
No, ldd will tell you what libraries are loaded into memory when running the
binary.
You want objdump -p | grep NEEDED instead.
But it was established a few weeks ago that linda's check used ldd by
mistake, and I haven't heard that it's been fixed
.4 and you're done.
Since the package installs public modules, it seems to me that putting the
modules and the app in a single package is the wrong solution.
However, trying to make the application package auto-switch between two
different versions of python is also the wrong soluti
On Thu, Apr 20, 2006 at 10:34:04PM +0200, Raphael Hertzog wrote:
> On Thu, 20 Apr 2006, Steve Langasek wrote:
> > denyhosts-python2.3/2.4 do contain a python module. If and when the Great
> > Python Reorganization finally happens, this ought to be a single denyhosts
> >
On Sun, Apr 23, 2006 at 06:33:04PM -0500, Joe Wreschnig wrote:
> On Thu, 2006-04-20 at 15:51 -0700, Steve Langasek wrote:
> > If it's not supposed to be a public module, it shouldn't be in a public
> > directory, and then there's no reason to provide more packages
o versions available.
> so that changed nothing.
what does update-alternatives --list x-cursor-theme list in this case?
It really looks to me like a u-a bug, not a bug in the calling maintainer
script.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Wed, Apr 26, 2006 at 05:38:22AM +, Sune Vuorela wrote:
> On 2006-04-26, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > what does update-alternatives --list x-cursor-theme list in this case?
> It shows nothing.
> [EMAIL PROTECTED]:/# update-alternatives --list x-
l: No such file or directory
> imake: Exit code 1.
> Stop.
> make: *** [build-stamp] Error 1
This looks like you have the wrong version of xutils-dev.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Mon, May 01, 2006 at 03:04:29PM +0200, Lionel Elie Mamane wrote:
> On Sun, Apr 30, 2006 at 08:33:49PM -0700, Russ Allbery wrote:
> > Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> >> Steve Langasek <[EMAIL PROTECTED]> writes:
> >>>> mv -f Make
ckage *may*
get built against the wrong ghc; if the package is binNMU-safe in the first
place, then all it takes to fix this is a binNMU...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EM
mand of English).
Wow, so the Japanese Debian developers we have that are reticent to
communicate with the project in the English language are in the bottom .1%
of the population?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to
NMUs. Nevertheless, the concept of a sponsored NMU is a broken
one, because responsibility for the NMU lies with the uploader, not with the
sponsoree.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to s
On Tue, May 30, 2006 at 02:04:00PM -0700, Don Armstrong wrote:
> On Tue, 30 May 2006, Bart Martens wrote:
> > On Tue, May 30, 2006 at 12:03:19PM -0700, Steve Langasek wrote:
> > > There are no technical measures in place which *prohibit*
> > > developers from sponsor
then install libsvn-javahl
- try to install libsvn-javahl on the same command line as the other
packages listed above, forcing apt (aptitude or apt-get) to find a
solution that lets you keep them all.
This is definitely off-topic for -mentors, though; if you need further help,
please see debi
cribership doesn't tend to have the depth of
experience to know about all the corner cases that might be relevant to
something like this.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
h&ver=2.1&arch=sparc&stamp=1149339169&file=log&as=raw
> Sparc is not keeping up.
Sparc is keeping up quite well, it's just not currently considered a release
candidate for reasons other than buildd power alone.
--
Steve Langasek Give me a lev
ctions.
No, you just need to not use dpatch and use quilt instead.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
bootstrap on your sarge machine to be able to
correctly bootstrap an etch or sid chroot.
And no, you should *not* build against an etch chroot if the intent is to
upload to unstable.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ers
^^^
And this is totally inappropriate in an NMU. NMUs should always be limited
to fixing bugs -- not making decisions that are exclusively the maintainer's
to make, like accepting comaintainers...
--
Steve Langasek Give me a lever long enough and a Free
r ask for
> comaintenance in a reasonable timeframe. What if I want to hijack the package
> in favour of a better maintenance ?
In that case, please consult the QA team for advice (and for formal MIA
tracking).
--
Steve Langasek Give me a lever long enough and a Free OS
D
sioned. Relationships with virtual packages can't be versioned, so
> your libldap2.2 doesn't satisfy the dependency.
Besides which, having a libldap package from OpenLDAP 2.2 claim to provide
libldap2 is broken in the extreme.
--
Steve Langasek Give me a lever lon
arch: any package... don't do that, because it will break
under binNMUs. :)
The documentation for this probably belongs in debian-policy; current
versions of policy seem to mention Source-Version, though, not the new
substvars, and I'm not sure if anyone has submitted a patch for this?
On Thu, Sep 14, 2006 at 12:55:47PM +0200, Goswin von Brederlow wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > If you want to declare a strict versioned dependency from an arch: all
> > package to an arch: any package... don't do that, because it will break
>
On Fri, Sep 15, 2006 at 09:47:34AM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 14 Sep 2006, Steve Langasek wrote:
> > > The BIG problem is how to get the next-version. Say you have version
> > > 1.2-3. A binNMU would be 1.2-3+b1, a security release would be
> >
installed.
> Should I simply ignore the lintian error?
The error is, if you don't *need* a specific version of the package, you
shouldn't depend on it at /all/. Essential means it's always available, so
there's no reason for you to depend on it.
--
Steve Langasek
1 - 100 of 604 matches
Mail list logo
