>
> Maybe two new parameters :
> package_list_update_command => "/usr/bin/aptitude update"
> package_list_update_ifelapsed => 60
> ?
>
> Jonathan
These attributes added, but not yet tested.
--
Mark Burgess
-
Professor of Network and System Admi
And Jonathan is still standing, while the others are cowering in their corners!
(I shall investigate this idea. It seems like a good solution.)
-- the referee
> It is nice to be able to limit the frequency of updates (ie, via
> ifelapsed, if one has a separate promise in a "commands" section).
> > I would recommend that you check if the install is successful and
> > run aptitude update if its not. If a updated package is published
> > since you ran "aptitude update" you will get a 404 on your request
> > for the older version. I think this would be the most elegant thing
> > to do, ins
On 26/01/2010 15:42, Tim Cutts wrote:
>
> On 26 Jan 2010, at 2:25 pm, Mark Burgess wrote:
>
>>
>> This seems reasonable. I am spoiled using zypper which does this
>> automatically.
>
> It's arguable that apt's separation of the two functions is sensible. I
> have more than 2000 machines; and have a
On 26 Jan 2010, at 3:13 pm, Andreas Dan Larsson wrote:
>
> I would recommend that you check if the install is successful and
> run aptitude update if its not. If a updated package is published
> since you ran "aptitude update" you will get a 404 on your request
> for the older version. I th
I would recommend that you check if the install is successful and run aptitude
update if its not. If a updated package is published since you ran "aptitude
update" you will get a 404 on your request for the older version. I think this
would be the most elegant thing to do, instead of failing to
So the best practice should be like this; :-)
commands:
debian|ubuntu.Hr00::
"/usr/bin/aptitude update";
packages:
debian|ubuntu::
"$(packages_to_be_installed)"
package_policy => "add",
package_method => aptitude;
body package_method aptitude
{
package_ad
I favour the idea of keeping apt-get update and apt-get upgrade separate.
In this manner I can schedule an update and know that subsequent upgrades
for all hosts will match the update schedule. This keeps your upgrades
all on the same time line.
Sincerely,
--
Neil Watson
416-673-3465
CONFIDE
And Tim is just knocking them down today!
;-)
1, 2, ...
Tim Cutts wrote:
>
> On 26 Jan 2010, at 2:41 pm, Nakarin Phooripoom wrote:
>
>> Zypper and yum seem to check and update the latest list of packages
>> every time it runs before installing any selected packages.
>>
>> Could we do somethin
On 26 Jan 2010, at 2:41 pm, Nakarin Phooripoom wrote:
> Zypper and yum seem to check and update the latest list of packages
> every time it runs before installing any selected packages.
>
> Could we do something like this for Debian/Ubuntu?
>
> package_add_command => "/usr/bin/aptitude update &
Doh! Strong left-hook from Tim. Will Jonathan come back for more?
M
Tim Cutts wrote:
>
> On 26 Jan 2010, at 2:25 pm, Mark Burgess wrote:
>
>>
>> This seems reasonable. I am spoiled using zypper which does this
>> automatically.
>
> It's arguable that apt's separation of the two functions is
Nice. Does this work for you, Jonathan?
Nakarin Phooripoom wrote:
> Zypper and yum seem to check and update the latest list of packages every
> time it runs before installing any selected packages.
>
> Could we do something like this for Debian/Ubuntu?
>
> package_add_command => "/usr/bin/apti
On 26 Jan 2010, at 2:25 pm, Mark Burgess wrote:
>
> This seems reasonable. I am spoiled using zypper which does this
> automatically.
It's arguable that apt's separation of the two functions is sensible.
I have more than 2000 machines; and have already once been blacklisted
by one apt rep
Zypper and yum seem to check and update the latest list of packages every time
it runs before installing any selected packages.
Could we do something like this for Debian/Ubuntu?
package_add_command => "/usr/bin/aptitude update && /usr/bin/aptitude
--assume-yes install";
Cheers,
--Nakarin
On
This seems reasonable. I am spoiled using zypper which does this automatically.
Jonathan Clarke wrote:
> On 25/01/2010 14:44, Jonathan Clarke wrote:
>> Hi,
>>
>> I've been testing the standard library, in particular the apt
>> package_method. I come with a bug and some suggestions.
>
> One furth
Actually, this is the same with apt-get (having to do "apt-get update").
I will work on a global patch to include this.
Jonathan
On 25/01/2010 17:02, Mark Burgess wrote:
>
> Since we didn't look at aptitude (no debian users in the office) we only made
> functionality that was supported in apt-g
Since we didn't look at aptitude (no debian users in the office) we only made
functionality that was supported in apt-get.
If you can set up and test the full thing for aptitude, that is a great service
to the
community.
Jonathan Clarke wrote:
> On 25/01/2010 14:44, Jonathan Clarke wrote:
>> Hi
On 25/01/2010 14:44, Jonathan Clarke wrote:
> Hi,
>
> I've been testing the standard library, in particular the apt
> package_method. I come with a bug and some suggestions.
One further question:
To "be aware" of new package, aptitude (or apt-get) must download the
latest list of packages from a
Great idea.
From Wikipedia (http://en.wikipedia.org/wiki/Aptitude_(software)):
8<--
As of the Debian 4.0 ("Etch") release of 2007, aptitude is "the
preferred program for package management from console both for package
installations and package or system upgrades."[1]
8<--
Please find a patc
This is good feedback. If we know the point at which aptitude came into play,
then we can
place classes in the body to separate, or test for it, e.g.
body package_method debian
{
have_aptitude::
!have_aptitude::
}
Jonathan Clarke wrote:
> Hi,
>
> I've been testing the standard
Hi,
I've been testing the standard library, in particular the apt
package_method. I come with a bug and some suggestions.
First off, the bug. package_update_command is set to "apt-get
dist-upgrade", which cause *all* packages to be updated to the latest
version, not just the one(s) we're updat
21 matches
Mail list logo
