On Mon, Mar 02, 2009 at 10:38:22AM +0100, Raphael Hertzog wrote:
You can certainly obtain a similar result nowadays by putting the
dependency that you want in debian/control directly and by using
the -x option of dpkg-shlibdeps to strip the dependency that you did not
want.
Except
On Sat, Feb 28, 2009 at 03:12:09PM +0100, Raphael Hertzog wrote:
On Sat, 28 Feb 2009, Julien BLACHE wrote:
Raphael Hertzog hert...@debian.org wrote:
debian/shlibs.local should help for that.
Except symbols files have priority over shlibs and there's no
symbols.local.
I sense a
On Sun, 01 Mar 2009, Steve Langasek wrote:
shlibs.local was initially a poor solution for a less than ideal
dpkg-shlibdeps that couldn't cope with shlibs just produced by the
packages being built.
Are you sure this was the reason? shlibs.local support was added to
dpkg-shlibdeps in
On Sat, 28 Feb 2009, Loïc Minier wrote:
I had a case recently where this wasn't too convenient with the ffmpeg
package: it depends on a bunch of libs split in their own packages in
the same source. The goal was to have a =binary:Version dep for ffmpeg
on these libs, and use a relaxed
On Sun, Mar 01, 2009, Raphael Hertzog wrote:
You can perfecly add a =binary:Version dependency in debian/control
directly, the relaxed dependency will be auto-removed by the
dpkg-gencontrol because it is implied by the former one.
Where's the problem ?
The problem is having to list a long
Sam Hartman hartm...@debian.org wrote:
Hi,
It turns out this fails impressively. The problem is that the library
packages depend on each other. So, for example, libk5crypto3 is
needed by libkrb5-3. If I make the shlibs file for libk5crypto3 point
to libkrb53 instead of libk5crypto3, then
On Sat, 28 Feb 2009, Julien BLACHE wrote:
Sam Hartman hartm...@debian.org wrote:
I probably could hack something that would work: use symbols files
that point at the split library packages internally and just before
the debs are constructed run a sed script on symbols and shlibs.
Raphael Hertzog hert...@debian.org wrote:
Hi,
debian/shlibs.local should help for that.
Except symbols files have priority over shlibs and there's no
symbols.local.
I sense a lack of flexibility in this symbols file feature, hmm.
JB.
--
Julien BLACHE - Debian GNU/Linux Developer -
On Sat, 28 Feb 2009, Julien BLACHE wrote:
Raphael Hertzog hert...@debian.org wrote:
Hi,
debian/shlibs.local should help for that.
Except symbols files have priority over shlibs and there's no
symbols.local.
I sense a lack of flexibility in this symbols file feature, hmm.
Julien == Julien BLACHE jbla...@debian.org writes:
Julien Sam Hartman hartm...@debian.org wrote: Hi,
It turns out this fails impressively. The problem is that the
library packages depend on each other. So, for example,
libk5crypto3 is needed by libkrb5-3. If I make the
On Sat, Feb 28, 2009, Raphael Hertzog wrote:
You can certainly obtain a similar result nowadays by putting the
dependency that you want in debian/control directly and by using
the -x option of dpkg-shlibdeps to strip the dependency that you did not
want.
I had a case recently where this
Hi Sam,
On Thu, Feb 26, 2009 at 11:40:45PM -0500, Sam Hartman wrote:
Sam 3) Make libkrb53 depend on all the libraries it now contains
Sam and libkadm55 depend on the libraries it contains.
Sam 4) Set up symbols and shlibs files to point everyone at
Sam libkrb53 and libkadm55
Steve == Steve Langasek vor...@debian.org writes:
Steve Actually, I was meaning to comment on this. Why would you
Steve not simply point the shlibs at the component library
Steve packages at this stage? The only side effect is that the
Steve version of krb5 that includes the
Sam == Sam Hartman hartm...@debian.org writes:
Sam OK, so I think we're all set. The plan now is to
Sam 1) Build twice, once into build and once into build-krb4. We
Sam only pull libkrb4.so out of build-krb4. 2)
This works at least.
Sam 3) Make libkrb53 depend on all the
Sam Hartman hartm...@debian.org wrote:
Hi,
That is, if I made the dependency in libkrb5-3.symbols look like
libkrb5-3|libkrb53 (and similar changes for other symbols files), then
both the packages in unstable and testing would satisfy the
dependencies. It seems like this would significantly
Julien == Julien BLACHE jbla...@debian.org writes:
Julien Sam Hartman hartm...@debian.org wrote: Hi,
That is, if I made the dependency in libkrb5-3.symbols look
like libkrb5-3|libkrb53 (and similar changes for other symbols
files), then both the packages in unstable and
Sam == Sam Hartman hartm...@debian.org writes:
Julien == Julien BLACHE jbla...@debian.org writes:
Julien Sam Hartman hartm...@debian.org wrote: Hi,
That is, if I made the dependency in libkrb5-3.symbols look
like libkrb5-3|libkrb53 (and similar changes for other symbols
Sam Hartman hartm...@debian.org wrote:
Hi,
Julien Have you considered uploading a version of krb5 with: -
Julien libkrb5-3 - libkrb4-? - libkrb53 a metapackage depending
Julien on both of the above - libkrb5-dev depending on libkrb5-3
Julien alone and containing only the
Julien == Julien BLACHE jbla...@debian.org writes:
I really appreciate your help here!
Julien As you note in your second reply, the goal is to decouple
Julien the packaging change from the krb4 dismissal: 1 introduce
Julien libkrb5-3 (Replaces: libkrb53), with libkrb53 depending on
Sam Hartman hartm...@debian.org wrote:
I really appreciate your help here!
Thanks!
I'm sorry, but I don't see how I get stuck in unstable if I start out
with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3
rather than libkrb53. As I understand it, rdeps can only hold me in
Sam Hartman hartm...@debian.org wrote:
Hi,
OK, so I think we're all set.
The plan now is to
Looks good!
1) Build twice, once into build and once into build-krb4. We only
pull libkrb4.so out of build-krb4. 2) Move all the libraries out of
libkrb53 and libkadm55 (sorry, in my previous
OK, so I think we're all set.
The plan now is to
1) Build twice, once into build and once into build-krb4. We only
pull libkrb4.so out of build-krb4. 2) Move all the libraries out of
libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying
a bit) except for libkrb4.so.2.
3)
[There are some questions at the end; comments would be greatly
appreciated on the questions if you have ever been involved in the
release process or library transitions before. This is my first big
transition.]
The libkrb53 package (providing the MIT Kerberos shared libraries) has
been stable
Just a couple of process notes.
Sam Hartman hartm...@debian.org writes:
I propose to upload a version of krb5 to unstable in about a week that
is basically identical to the krb5 in experimental. I will include some
debconf fixes, a news file, and other minor changes. See the
experimental
24 matches
Mail list logo
