Graham Williams wrote:

>Received Sat 18 Jun 2005  1:10pm +1000 from David Liontooth:
>  
>
>>Package: wajig
>>Version: 2.0.27
>>Severity: wishlist
>>
>>
>>It would be very useful to be able to install all new or all newupgrade 
>>packages, 
>>perhaps simply by allowing "install" as a parameter to those commands:
>>
>>      wajig new install
>>      wajig newupgrade install
>>
>>Another solution would be to allow the list of new packages to be piped to a 
>>format
>>that could be used by wajig install-file.
>>    
>>
>
>  
>
Hi Graham,

>Hi Dave,
>
>Thanks for the suggestion. I'm not quite sure I see the use of it!
>You could achieve it with the following:
>
>    wajig new | tail +3 | cut -d' ' -f1 | xargs wajig install
>
>or 
>
>    wajig newupgrades | tail +3 | cut -d' ' -f1 | xargs wajig install
>  
>
Cool! That works for me.

>
>... it does need extra work and knowledge of the Linux tools.
>  
>
You know, maybe you could add some of these extras to a README or
similar -- it's very educational.

>
>For "new" would you really want to install all of the new packages at
>any time?  I simply cut and past the ones I want onto the command
>line.
>  
>
That is what I normally do, and in the case of new, installing all of
them would not be common.
A simple way of piping them to a list that could be used by install-file
would do.

>For "newupgrades" why would you want to do this rather than "distupgrade"?
>  
>
Very different! Distupgrade would pick up everything in "toupgrade",
which exposes you to a somewhat greater level of risk for broken
packages. On production systems, I don't track the bleeding edge of sid,
but instead hang back on very minor upgrades, which happen all the time. 

Sid often has 30-50 upgrades, and if I want most of them (while at the
same time leaving a pool of un-upgraded packages), I have to cut and
paste fifty times, for several machines, several times a week, or I
could hire someone to cut and paste for me at a penny a cut and a penny
a paste, while the dog barks and my students want their grades. Wajig I say!

I'm happy with workarounds though -- I use wajig status | grep 4:3.3.2 |
grep 4:3.3.1 | cut -f1 > list that you suggested earlier for a similar
type problem.

>They are both easy enough to implement, and as a user you obviously
>would find it useful. So I'll do it! Would like to understand how you
>find them useful though and I'll document it.
>  
>
Piping is actually preferable to an indiscriminate install -- I retract
my suggestion in light of your workarounds, and suggest documenting
those instead.

Best,
Dave

>
>  
>
>>Dave
>>
>>
>>-- System Information:
>>Debian Release: sid
>>  APT prefers unstable
>>  APT policy: (500, 'unstable')
>>Architecture: i386 (i686)
>>Shell:  /bin/sh linked to /bin/bash
>>Kernel: Linux 2.6.12-rc2
>>Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
>>
>>Versions of packages wajig depends on:
>>ii  apt                           0.5.28.1   Advanced front-end for dpkg
>>ii  python                        2.3.5-1    An interactive high-level 
>>object-o
>>ii  python-apt                    0.5.10     Python interface to libapt-pkg
>>
>>wajig recommends no packages.
>>
>>Versions of packages wajig is related to:
>>ii  reportbug                     3.13       reports bugs in the Debian 
>>distrib
>>pn  totem-gstreamer               <none>     (no description available)
>>
>>-- no debconf information
>>
>>    
>>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to