> Hello Adrian,
Hello Frank,
first of all sorry for my late answer.
>...
> So okay, I think that we might get rid of libkpathsea3 faster if we
> rename libkpathsea4-dev to libkpathsea-dev, and request binary NMUs if
> needed. But there's one thing left I'm not sure about:
>
> If the tetex-bin
Hello Adrian,
Having thought about this, I come to the conclusion that you are right
(with some small caveat, see below). But I'd like to tell you why it
took me so long, and caused a sometimes emotional discussion.
When you submitted the bug and subsequently were told that there were
already pl
On Fri, Mar 03, 2006 at 10:41:32PM +0100, Frank Küster wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>...
> > The advantage of the libkpathsea4-dev -> libkpathsea-dev is that the
> > packages build depending on libkpathsea-dev will automatically move to
> > libkpathsea4.
>
> Only *if* they are
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Sending a patch for #354508 would be silly since all it takes is adding
> one letter to debian/control, and I can't believe that you think the
> maintainer of the package would be dumb enough for not seeing this from
> the bug report.
- You could explai
On Fri, Mar 03, 2006 at 07:37:55PM +0100, Frank Küster wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > As I said earlier in this bug:
> >
> > <-- snip -->
> >
> > Now that teTeX 3.0 is in testing and these testing-specific issues are
> > no longer an issue, would you expect any problems wi
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> As I said earlier in this bug:
>
> <-- snip -->
>
> Now that teTeX 3.0 is in testing and these testing-specific issues are
> no longer an issue, would you expect any problems with simply renaming
> libkpathsea4-dev to libkpathsea-dev (and providing libkpa
On Fri, Mar 03, 2006 at 10:16:17AM +0100, Frank Küster wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> >> But that still leaves us with Olaf's statement that he is unsure about
> >> the API.
> >
> > That's not that hard to check.
> >
> > The API is defined through the header files, and below i
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>> But that still leaves us with Olaf's statement that he is unsure about
>> the API.
>
> That's not that hard to check.
>
> The API is defined through the header files, and below is a complete
> diff of the header files.
>
> The only thing that looks slight
On Thu, Mar 02, 2006 at 07:22:56PM +0100, Frank Küster wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > Your example is irrelevant since this is a difference between different
> > teTeX versions but not between libkpathsea3 and libkpathsea4.
> >
> > The proof is simple (./kpsewhich is the pr
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Your example is irrelevant since this is a difference between different
> teTeX versions but not between libkpathsea3 and libkpathsea4.
>
> The proof is simple (./kpsewhich is the program from sarge (linked with
> libkpathsea3) copied to an unstable syste
On Thu, Mar 02, 2006 at 06:48:12PM +0100, Frank Küster wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > AFAIK, there are no known API changes in libkpathsea4
>
> Please read this sentence loud, pronounce every word of the acronym, and
> try not to think of George Doubleju. You know, there
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> AFAIK, there are no known API changes in libkpathsea4
Please read this sentence loud, pronounce every word of the acronym, and
try not to think of George Doubleju. You know, there are known knows,
and unknown knowns, or how was it? ;-)
Unfortunately I c
On Wed, Mar 01, 2006 at 05:25:09PM +0100, Frank Küster wrote:
>...
> > - people using self-compiled programs linked with libkpathsea (which
> > should be quite rare) can simply keep libkpathsea3 on their system
> > no matter that it's removed from etch
> > - Debian doesn't keep two so-version
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 27, 2006 at 12:44:19PM +0100, Florent Rougon wrote:
>> Hi,
>>
>> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>>
>> > Package: libkpathsea3
>> > Version: 2.1-1
>> > Severity: normal
>> >
>> >
>> > The only reason for shipping with both libkpathsea3
Hi all,
From: Adrian Bunk <[EMAIL PROTECTED]>
Subject: Bug#354507: libkpathsea3 should be removed
Date: Mon, 27 Feb 2006 16:08:15 +0100
> I'm not understanding the rationale for "not removing before etch+1":
> - it has zero use inside Debian
I'm not sure w
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> I'm not understanding the rationale for "not removing before etch+1":
I cannot tell. I told you what I remembered having read here (IIRC), but
if you want more precisions, you'll have to wait for Frank.
Regards,
--
Florent
--
To UNSUBSCRIBE, email t
On Mon, Feb 27, 2006 at 12:44:19PM +0100, Florent Rougon wrote:
> Hi,
>
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > Package: libkpathsea3
> > Version: 2.1-1
> > Severity: normal
> >
> >
> > The only reason for shipping with both libkpathsea3 and libkpathsea4
> > was to work around one of the s
Hi,
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Package: libkpathsea3
> Version: 2.1-1
> Severity: normal
>
>
> The only reason for shipping with both libkpathsea3 and libkpathsea4
> was to work around one of the shortcomings of testings.
IIRC, Frank wanted to have no package using libkpathsea3 in
Package: libkpathsea3
Version: 2.1-1
Severity: normal
The only reason for shipping with both libkpathsea3 and libkpathsea4
was to work around one of the shortcomings of testings.
Now that libkpathsea4 is in testing, libkpathsea3 should be removed
and the remaining users forced to switch to libkp
19 matches
Mail list logo
