On Fri, Aug 01, 2003 at 07:30:20AM +0200, Matthias Urlichs wrote:
> > But presumably you _would_ have a problem with:
> > - the old library trying to look up a string which isn't there anymore in
> > the new library
> > - the new library trying to look up a string which isn't there in the old
>
On Aug 1, Matthias Urlichs ([EMAIL PROTECTED]) wrote:
> Hi, Matt Zimmerman wrote:
>
> > But presumably you _would_ have a problem with:
> > - the old library trying to look up a string which isn't there anymore in
> > the new library
> > - the new library trying to look up a string which
On Fri, Aug 01, 2003 at 07:30:20AM +0200, Matthias Urlichs wrote:
> > But presumably you _would_ have a problem with:
> > - the old library trying to look up a string which isn't there anymore in
> > the new library
> > - the new library trying to look up a string which isn't there in the old
>
On Aug 1, Matthias Urlichs ([EMAIL PROTECTED]) wrote:
> Hi, Matt Zimmerman wrote:
>
> > But presumably you _would_ have a problem with:
> > - the old library trying to look up a string which isn't there anymore in
> > the new library
> > - the new library trying to look up a string which
Hi, Matt Zimmerman wrote:
> But presumably you _would_ have a problem with:
> - the old library trying to look up a string which isn't there anymore in
> the new library
> - the new library trying to look up a string which isn't there in the old
> library
Of course the message catalog would c
Hi, Matt Zimmerman wrote:
> But presumably you _would_ have a problem with:
> - the old library trying to look up a string which isn't there anymore in
> the new library
> - the new library trying to look up a string which isn't there in the old
> library
Of course the message catalog would c
On Thu, Jul 31, 2003 at 04:34:53PM +0200, Matthias Urlichs wrote:
> > This would only be feasible if the message catalog never changed.
> > Presumably, it corresponds to translated strings in the library, which
> > might not be identical in different versions of the library.
>
> Personally I don'
Hi, Matt Zimmerman wrote:
> This would only be feasible if the message catalog never changed.
> Presumably, it corresponds to translated strings in the library, which
> might not be identical in different versions of the library.
Personally I don't have a problem with the old library "acquiring"
On Thu, Jul 31, 2003 at 04:34:53PM +0200, Matthias Urlichs wrote:
> > This would only be feasible if the message catalog never changed.
> > Presumably, it corresponds to translated strings in the library, which
> > might not be identical in different versions of the library.
>
> Personally I don'
Hi, Matt Zimmerman wrote:
> This would only be feasible if the message catalog never changed.
> Presumably, it corresponds to translated strings in the library, which
> might not be identical in different versions of the library.
Personally I don't have a problem with the old library "acquiring"
On Thu, Jul 31, 2003 at 06:57:51AM -0400, Neil Roeth wrote:
> > If the message files are identical, another solution would be to create a
> > third package with the message files which you depend on in the library
> > packages. (The former should of course conflict with older versions
> > of t
On Jul 30, Matt Zimmerman ([EMAIL PROTECTED]) wrote:
> You should either version the files, or move them into another package.
On Jul 31, Matthias Urlichs ([EMAIL PROTECTED]) wrote:
> Hi, Paul.Hampso wrote:
>
> > Look up 'Replaces' in the policy or developer's guide or whatnot.
>
> The two
On Thu, Jul 31, 2003 at 06:57:51AM -0400, Neil Roeth wrote:
> > If the message files are identical, another solution would be to create a
> > third package with the message files which you depend on in the library
> > packages. (The former should of course conflict with older versions
> > of t
On Jul 30, Matt Zimmerman ([EMAIL PROTECTED]) wrote:
> You should either version the files, or move them into another package.
On Jul 31, Matthias Urlichs ([EMAIL PROTECTED]) wrote:
> Hi, Paul.Hampso wrote:
>
> > Look up 'Replaces' in the policy or developer's guide or whatnot.
>
> The two
Hi, Paul.Hampso wrote:
> Look up 'Replaces' in the policy or developer's guide or whatnot.
The two libraries need to coexist peacefully. Replaces: doesn't help here.
If the message files are identical, another solution would be to create a
third package with the message files which you depend on
Hi, Paul.Hampso wrote:
> Look up 'Replaces' in the policy or developer's guide or whatnot.
The two libraries need to coexist peacefully. Replaces: doesn't help here.
If the message files are identical, another solution would be to create a
third package with the message files which you depend on
and libgtk1.2-common versionize the locale
> files, e.g., gtk20.mo and gtk+.mo, respectively. I'm not certain that it was
> done to solve the same problem, but it looks like that would work in my case.
> Is there any reason not to do that?
You should either version the files, or move t
and libgtk1.2-common versionize the locale
> files, e.g., gtk20.mo and gtk+.mo, respectively. I'm not certain that it was
> done to solve the same problem, but it looks like that would work in my case.
> Is there any reason not to do that?
Look up 'Replaces' in the policy or developer's guide or whatnot.
--
Paul "TBBle" Hampson
on a
system that has libosp2 installed, I get an error: "trying to overwrite
`/usr/share/locale/de/LC_MESSAGES/sp.mo', which is also in package libosp2".
I found that libgtk2.0-common and libgtk1.2-common versionize the locale
files, e.g., gtk20.mo and gtk+.mo, respectively. I
and libgtk1.2-common versionize the locale
> files, e.g., gtk20.mo and gtk+.mo, respectively. I'm not certain that it was
> done to solve the same problem, but it looks like that would work in my case.
> Is there any reason not to do that?
You should either version the files, or move t
and libgtk1.2-common versionize the locale
> files, e.g., gtk20.mo and gtk+.mo, respectively. I'm not certain that it was
> done to solve the same problem, but it looks like that would work in my case.
> Is there any reason not to do that?
Look up 'Replaces' in the policy or dev
on a
system that has libosp2 installed, I get an error: "trying to overwrite
`/usr/share/locale/de/LC_MESSAGES/sp.mo', which is also in package libosp2".
I found that libgtk2.0-common and libgtk1.2-common versionize the locale
files, e.g., gtk20.mo and gtk+.mo, respectively. I
22 matches
Mail list logo
