Question about locking packages

[Thomas Röhl]

Hi everybody,

After I read over my mail I realized many things that are confusing.

"We" is the Linux-Department of the University Erlangen-Nürnberg. We 
have changed almost all servers and clients to smart running SLES9, 
SLES10, OpenSuSE 10.0 and openSuSE 10.1.

"When you lock a package you're asking Smart not to allow these packages 
to be changed. If you want to change these packages all you have to do 
is unlocking them"

Jop, thats right and thats what we need because we want to lock the 
kernel and than install the kernel in a scheduled order through cfengine.

The "soft lock" idea is exactly what we need. If a package is softlocked 
than the upgrade process simply writes out the problem at the end and 
will not upgrade all the packages. (Like apt: Kept back: 1) We automated 
all the smart-stuff an get Emails for every host with their update-status.

I thought about writing a skript around smart to do this, but I thought 
that many people could need this too. I normally only use python so 
maybe I can write it by myself, but I dont want to read the whole source 
code. O:-)

MFG
Thomas Röhl


Gustavo Niemeyer wrote:
> Hello Thomas,
>
>   
>> Recently we decided to replace the whole apt-rpm with smart.
>> Now I got a 
>>     
>
> Interesting. Who are "we" and how's the process going?
>
>   
>> problem with locking packages which actually should only be kept back 
>> til I give the signal to install them.
>>
>> I consider something like this:
>>
>> smart upgrade shows all locked packages
>> -> compare locked packages with the output of smart flag --show lock
>> -> give smart an option like smart upgrade --really-all to update also 
>> locked packages or smart upgrade <packagename> to upgrade this locked 
>> package.
>>
>> Does anyone has a script to do this. maybe via cron? Or is there a 
>> workaround for this problem?
>>     
>
> I'm not sure I understand the problem you're trying to solve. When you
> lock a package you're asking Smart not to allow these packages to be
> changed. If you want to change these packages all you have to do is
> unlocking them (that's the equivalent of --really-all).
>
> Perhaps what you're looking for is a "soft lock" that prevents the
> package from being upgraded automatically. But in this case, what
> happens if the package is being required by another package that
> will be upgraded (isn't "soft locked")?
>
>