[csw-maintainers] dbus

[Dagobert Michelsen]

Hi,

Am 13.01.2010 um 21:13 schrieb Sebastian Kayser:
> Jeffery Small wrote on 13.01.2010 20:57:
>> Dagobert Michelsen <dam at opencsw.org> writes:
>>
>>> This was announced together with the updated package on users@
>>> in September:
>>
>>> If dbus is running, it will be stop during update, thus update may  
>>> freeze.
>>> In order to avoid this situation, you have to be sure that you  
>>> don't have
>>> dbus running, or if it is running, you will have to kill it by  
>>> hand before
>>> the upgrade.  You can retrieve the pid to kill with the [...]
>>
>> Thanks Dagobert.
>>
>> I'm sorry that I missed the announcement back in September.  I  
>> followed the
>> procedures and did get the updated package installed.  I really  
>> appreciate
>> the quick response.  Two comments:
>>
>> 1) It would be good to get the news section for packages up and  
>> running so
>> that information like this could be used to list important  
>> information like
>> this.
>
> +1
>
> The NEWS link on www.opencsw.org/packages/<package> points to the  
> Mantis
> news page for a package. Each maintainer should be able to populate  
> this
> section for his packages already. That's where important news about  
> that
> package could go. Nothing fancy, but better than it is right now.

This is definitely a good idea. We also have
   http://wiki.opencsw.org/packages
Too many places for so simple things...

> What I also really would like to see is a changelog.CSW shipped with
> each package which is somehow hooked into the release process. The  
> NEWS
> section could then be automatically updated. I just had a
> troubleshooting session with someone who updated amavisd-new and from
> the package side it took me some time of distilling the important  
> items
> in the GAR logs to see what had changed. That's where the NEWS would
> have been helpful also.

The package news section should IMHO have one entry per release.
The ChangeLog is usually updated on every edit session which may
or may not result in a released package, so I'd propose a modified
approach here.

>> 2) Is there some reason that the test for the bad installed version  
>> of
>> dbus was not performed by the package's install script and then  
>> have the
>> script automatically check for a running process and kill it as  
>> part of
>> the upgrade procedure, rather than force the user to perform a manual
>> intervention?  I ask this as a general question regarding all  
>> packages that
>> might require a non-standard form of intervention during  
>> installation.
>
> The bad dbus package was already installed and in my case it was the
> uninstallation that hung. Nothing that the new package could have  
> dealt
> with, or?

I think so, yes. Upgrade-triggers would help circumvent these kinds of
problems.


Best regards

   -- Dago