[csw-maintainers] Killing the stable release

[Maciej (Matchek) Bliziński]

2012/3/19 Dagobert Michelsen <dam at opencsw.org>:
> Hi Maciej,
>
> Am 17.03.2012 um 21:24 schrieb Maciej Bliziński:
>> Dagobert Michelsen wrote:
>>> Am 15.03.2012 um 10:57 schrieb Peter Bonivart:
>>>> 2012/3/15 Maciej (Matchek) Bliziński <maciej at opencsw.org>:
>>>>> In the case of stable, there is not much breakage. Maybe the only
>>>>> breakage would be when someone has a machine running stable, and they
>>>>> want to install a new package that they haven't installed before. That
>>>>> wouldn't work after the rename. They'd have to reconfigure
>>>>> pkgutil.conf to point at stable-dead, that's all.
>>>>
>>>> Pkgutil will fail without "injury". I see two cases, you have an up to
>>>> date catalog, then the actual file fetching will fail and pkgutil
>>>> aborts. Otherwise, the catalog fetching will fail and pkgutil aborts.
>>>> In both cases no changes are made to your system.
>>>
>>> I suggest having three extra file
>>>  00PACKAGENOTFOUND
>>>  00CATALOGNOTFOUND
>>>  00MOTD
>>
>> Would that be in the catalog leve? E.g. unstable/sparc/5.10
>
> Yes.
>
>> Why have them split into separate files? This could be all folded into
>> one record based file with a simple syntax.
>
> That would also be possible if necessary, but this was the simplest possible
> form also usable if someone browses a ftp share.
>
>>> If a package could not be found the first is tried to be download and
>>> displayed. If it is not there nothing happens. If a catalog could not
>>> be found the second is displayed. The third is tried and displayed on
>>> every update (-U).
>>
>> I also thought that the message for package not found could vary
>> depending on the package. For example, a note for a removed package
>> could be added.
>
> Yes, like <catalogname>.info containing stuff printed if the corresponding
> package could no be found. Good point.

This needs to be implemented, and unless someone takes it on, we won't
have it. If no one can implement this, I suggest we revert to the
simpler plan of:

mv stable stable-dead

This is something we can easily do, and it will accomplish the primary
goal: communicating to users that stable is dead.