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.
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
On Sat, Feb 28, 2009 at 03:12:09PM +0100, Raphael Hertzog wrote:
> On Sat, 28 Feb 2009, Julien BLACHE wrote:
> > Raphael Hertzog wrote:
> > >> 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
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 l
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 v
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 w
> "Julien" == Julien BLACHE writes:
Julien> Sam Hartman 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 libk
On Sat, 28 Feb 2009, Julien BLACHE wrote:
> Raphael Hertzog 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.
shlibs.local
Raphael Hertzog 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 -
Public key a
On Sat, 28 Feb 2009, Julien BLACHE wrote:
> Sam Hartman 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.
>
> debian/shlibs.loca
Sam Hartman 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 libkrb5-3 depend
> "Steve" == Steve Langasek 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 split lib
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 lib
> "Sam" == Sam Hartman 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 libraries
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) Make
Sam Hartman 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 mails I was si
Sam Hartman 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
> unstable if movin
> "Julien" == Julien BLACHE 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
Julie
Sam Hartman 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 files needed to
> "Sam" == Sam Hartman writes:
> "Julien" == Julien BLACHE writes:
Julien> Sam Hartman 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 uns
> "Julien" == Julien BLACHE writes:
Julien> Sam Hartman 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
Sam Hartman 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 reduce the
> im
Just a couple of process notes.
Sam Hartman 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 branch of [2] for
[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 f
24 matches
Mail list logo
