David Kalnischkies writes:
> 2010/6/6 Ludovic Brenta :
>> Package: gnat
>> Architecture: any
>> Depends: gnat-4.4 (>= 4.4.2-1)
>> Recommends: ada-reference-manual, gnat-gps
>> Breaks: libadasockets-dev (<= 1.8.6-2), libasis-dev, libaunit-dev,
>> libaws-dev, libflorist-dev, libgnademysql-dev, libgn
2010/6/6 Ludovic Brenta :
> Package: gnat
> Architecture: any
> Depends: gnat-4.4 (>= 4.4.2-1)
> Recommends: ada-reference-manual, gnat-gps
> Breaks: libadasockets-dev (<= 1.8.6-2), libasis-dev, libaunit-dev,
> libaws-dev, libflorist-dev, libgnademysql-dev, libgnadeodbc-dev,
> libgnadepostgresql-
(better late than never)
2010/6/3 Ludovic Brenta :
> Jacob Sparre Andersen writes:
>> David Kalnischkies wrote:
>>> With the break you can force the update of old-libs, which
>>> could depend in their new version on the new-libs.
>
> OK, I just tried that (in a local repository). Having gnat brea
(better late than never)
2010/6/1 Jacob Sparre Andersen :
> David Kalnischkies wrote:
>> 2010/5/31 Ludovic Brenta :
>>> Question 2: if I add Breaks: to a -dev package, which ones of Conflicts:
>>> and Replaces: should I also specify? (currently, both are specified; the new
>>> packages replace alm
Jacob Sparre Andersen writes:
> David Kalnischkies wrote:
>> 2010/5/31 Ludovic Brenta :
>
>>> Option 1: upload a new package "gnat" that Breaks: all -dev
>>> packages that were present in Lenny but are no longer present in
>>> Squeeze. This however does not really help apt, or the user,
>>> discove
David Kalnischkies wrote:
2010/5/31 Ludovic Brenta :
Option 1: upload a new package "gnat" that Breaks: all
-dev packages that were present in Lenny but are no
longer present in Squeeze. This however does not really
help apt, or the user, discover the new replacement
packages.
Option 2: c
2010/5/31 Ludovic Brenta :
> Option 1: upload a new package "gnat" that Breaks: all -dev packages
> that were present in Lenny but are no longer present in Squeeze.
> This however does not really help apt, or the user, discover the
> new replacement packages.
>
> Option 2: change each new -dev pack
David Kalnischkies wrote:
> The only thing i can see from this "hint" is that dependencies are
> missing. Fine, i guess i have talked about nothing else so far.
> Whatever causes the removal of gnat-4.3 can e.g. also "Breaks"
> all the packages who missed proper dependencies before.
(side note: I
2010/5/31 Ludovic Brenta :
> David Kalnischkies wrote:
>> 2010/5/30 Ludovic Brenta :
>>> The consequence is that, despite the fact that these packages are
> broken
>>> (without the need for a Breaks: in their successor packages, BTW),
>>> aptitude prefers to leave them installed rather than remove
David Kalnischkies wrote:
> 2010/5/30 Ludovic Brenta :
>> The consequence is that, despite the fact that these packages are
broken
>> (without the need for a Breaks: in their successor packages, BTW),
>> aptitude prefers to leave them installed rather than remove them; this
>> in turn blocks upgra
2010/5/30 Ludovic Brenta :
> David Kalnischkies writes:
>> 2010/5/29 Ludovic Brenta :
>>> David Kalnischkies writes:
No. Replaces is used to say to dpkg: It is okay that this package
overrides files of the other package - otherwise dpkg would complain
loudly for good reasons. It do
David Kalnischkies writes:
> 2010/5/29 Ludovic Brenta :
>> David Kalnischkies writes:
>>> No. Replaces is used to say to dpkg: It is okay that this package
>>> overrides files of the other package - otherwise dpkg would complain
>>> loudly for good reasons. It doesn't say something about the
>>>
2010/5/29 Ludovic Brenta :
> David Kalnischkies writes:
>> No. Replaces is used to say to dpkg: It is okay that this package
>> overrides files of the other package - otherwise dpkg would complain
>> loudly for good reasons. It doesn't say something about the
>> upgrade path.
>
> I disagree with t
David Kalnischkies writes:
> No. Replaces is used to say to dpkg: It is okay that this package
> overrides files of the other package - otherwise dpkg would complain
> loudly for good reasons. It doesn't say something about the
> upgrade path.
I disagree with this particular part of your analysis
David Kalnischkies writes:
> 2010/5/28 Stephen Leake :
>> Ludovic Brenta writes:
>>
>>> Stephen Leake wrote:
Ludovic Brenta writes:
> The reason for all this is that when a package libX2-dev Conflicts:
>>> with
> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
2010/5/28 Stephen Leake :
> Ludovic Brenta writes:
>
>> Stephen Leake wrote:
>>> Ludovic Brenta writes:
The reason for all this is that when a package libX2-dev Conflicts:
>> with
and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
and install libX2-dev; instead,
Stephen Leake wrote:
Currently, a package is upgraded only if its name does not change.
Good point.
Is the hack then to introduce a new "lib-dev"
package which is empty but depends on
"lib-dev"?
Lots of empty packages, just to get the upgrade to work, but
if we have a plan for avoiding t
Ludovic Brenta writes:
> Stephen Leake wrote:
>> Ludovic Brenta writes:
>>> The reason for all this is that when a package libX2-dev Conflicts:
> with
>>> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
>>> and install libX2-dev; instead, it marks libX1-dev as broken and le
Stephen Leake wrote:
> Ludovic Brenta writes:
>> The reason for all this is that when a package libX2-dev Conflicts:
with
>> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
>> and install libX2-dev; instead, it marks libX1-dev as broken and leaves
>> libX2-dev uninstalled.
Ludovic Brenta writes:
> Over the last two weeks I have been testing upgrades of Ada packages
> from Lenny to Sid and Squeeze in a chroot.
Thanks for looking at this.
> ...
> The reason for all this is that when a package libX2-dev Conflicts: with
> and Replaces: a package libX1-dev, aptitude
Jacob Sparre Andersen wrote:
> Ludovic Brenta wrote:
>
>> Over the last two weeks I have been testing upgrades of
>> Ada packages from Lenny to Sid and Squeeze in a chroot.
>> The picture is not as pretty as it should be. In a
>> nutshell, when you change /etc/apt/sources.list from lenny
>>
Ludovic Brenta wrote:
Over the last two weeks I have been testing upgrades of
Ada packages from Lenny to Sid and Squeeze in a chroot.
The picture is not as pretty as it should be. In a
nutshell, when you change /etc/apt/sources.list from lenny
to squeeze (unstable, actually) and do "aptitude
22 matches
Mail list logo
