Packages install naming scope

[Nicolas Ecarnot]

Hi,

I'm trying to install a set of packages, so I'm using something like this :

        vars:
                "desired_packages"
                        slist => {
                                "net-snmp",
                                "wget",
                                "iotop",
                        };

        packages:
                        "$(desired_packages)"
                                package_policy => "add",
                                package_method => generic;

When typing on the command line "yum install man", the regexp is not greedy and the shortest version of the package name is found, and a single package is installed.
When using the method above, to many additional packages are found and installed.
I've seen one can force specific regexp when installing package.

But the issue is that the dash sign sometimes is desired and sometimes not :

I *want* :

vim-common
vim-minimal

but I don't want :

vim-X11

AND the issue is that their rpm names are :
vim-minimal-7.2.411-1.8.el6.x86_64
vim-common-7.2.411-1.8.el6.x86_64

To sum up, the issue is that the dash sign is part of the package name, and can not be considered a valid separator of the version numbers. Obviously, there are a dozen of different cases that break the regexp I could imagine (several dashes, no dashes, numbers in name...)

How do you cope with such issues?

Best regards,

--
Nicolas Ecarnot

[Neil Watson]

Related bug below. Looks like it might be fixed on 3.6. What version are
you using?

https://dev.cfengine.com/issues/2986

--
Neil H Watson
Sr. Partner, Architecture and Infrastructure
CFEngine reporting: https://github.com/evolvethinking/delta_reporting
CFEngine policy: https://github.com/evolvethinking/evolve_cfengine_freelib
CFEngine and vim: https://github.com/neilhwatson/vim_cf3
CFEngine support: http://evolvethinking.com

[Danilo Chilene]

Hi,

I just install vim-enhanced.

--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengine+unsubscribe@googlegroups.com.
To post to this group, send email to help-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/help-cfengine.
For more options, visit https://groups.google.com/d/optout.

[Nicolas Ecarnot]

Hi,

Le mercredi 27 août 2014 16:03:26 UTC+2, Neil Watson a écrit :

Related bug below. Looks like it might be fixed on 3.6. What version are
you using?

I'm using 3.6.0-1.
When trying a yum upgrade, I see a 3.6.1-1 is waiting for me. I'm trying to upgrade it now and tell you if it helps.
 

https://dev.cfengine.com/issues/2986

I read this ticket.
Things I can witness is :
- using method 'generic' or 'yum' produces the same bad result
- using yum on the command line only installs the minimum I want.

For bicofino, yes, there are packages where one can workaround using some hints, but there is clearly a bug that has to be solved.

--
Nicolas Ecarnot

[Nicolas Ecarnot]

Le mercredi 27 août 2014 16:51:03 UTC+2, Nicolas Ecarnot a écrit :

Hi,

Le mercredi 27 août 2014 16:03:26 UTC+2, Neil Watson a écrit :

Related bug below. Looks like it might be fixed on 3.6. What version are
you using?

I'm using 3.6.0-1.
When trying a yum upgrade, I see a 3.6.1-1 is waiting for me. I'm trying to upgrade it now and tell you if it helps.

Ok, I upgraded in 3.6.1-1, rebooted the hub, and the same issue arises :
When installing the ntp packages, I also get ntp-perl, ntp-doc...
Same action with yum on the command line only installs ntp.

https://dev.cfengine.com/issues/2986

Please, may you explain why this bug has been closed?

--
Nicolas Ecarnot

[Ted Zlatanov]

On Wed, 27 Aug 2014 07:59:37 -0700 (PDT) Nicolas Ecarnot <nicolas...@gmail.com> wrote:

NE> Ok, I upgraded in 3.6.1-1, rebooted the hub, and the same issue arises :
NE> When installing the ntp packages, I also get ntp-perl, ntp-doc...
NE> Same action with yum on the command line only installs ntp.

NE> https://dev.cfengine.com/issues/2986

NE> Please, may you explain why this bug has been closed?

Use `package_latest` or `package_present` as needed. You can look at
their implementation to figure out what you're doing wrong, if you want
to know the internals.

https://docs.cfengine.com/docs/master/reference-standard-library-packages.html#package_latest

Ted

[Nicolas Ecarnot]

Le mercredi 27 août 2014 21:14:51 UTC+2, Ted Zlatanov a écrit :

Use `package_latest` or `package_present` as needed.

Ok I surrender.
As a newbie, I tried to read and implement a solution based on a mix between my cf script and the usage of package_latest, but there are still too many things I don't know with the cfengine DSL.
May you please post a sample of a cf script that makes use of package_latest?

--
Nicolas Ecarnot

[Neil Watson]

There are new package bundles in stdlib that may take care of the
version logic for you, or give you hints on how to fix your own bundle.

https://github.com/cfengine/masterfiles/blob/master/lib/3.6/packages.cf#L1816
https://github.com/cfengine/masterfiles/blob/master/lib/3.6/packages.cf#L1779

Sincerely,

[Ted Zlatanov]

On Wed, 27 Aug 2014 15:14:19 -0400 Ted Zlatanov <t...@lifelogs.com> wrote:

TZ> https://docs.cfengine.com/docs/master/reference-standard-library-packages.html#package_latest

On Thu, 28 Aug 2014 07:26:30 -0700 (PDT) Nicolas Ecarnot <nicolas...@gmail.com> wrote:

NE> Le mercredi 27 août 2014 21:14:51 UTC+2, Ted Zlatanov a écrit :
>>
>> Use `package_latest` or `package_present` as needed.
>>

NE> Ok I surrender.
NE> As a newbie, I tried to read and implement a solution based on a mix
NE> between my cf script and the usage of package_latest, but there are still
NE> too many things I don't know with the cfengine DSL.
NE> May you please post a sample of a cf script that makes use of
NE> package_latest?

I'm not sure why you cut out the URL, since it has exactly the example
you needed!

You need to put it in a bundle (but you probably already have that in
promises.cf), so the full standalone version in 3.6 and later would be:

body common control
{
bundlesequence => { run };
inputs => { "$(sys.libdir)/stdlib.cf" };
}

bundle agent run
{
methods:
"latestzip" usebundle => package_latest("zip");
}

HTH
Ted

[Nicolas Ecarnot]

Well, thank you Ted and Neil,

Actually, I was already using the same bundle you posted. I stored it into masterfiles, and ran it standalone from here.
I did... nothing. Verbose mode did not show any evidence of missing things.
Removing the bundlesequence, calling it from the usual promises.cf did work !

I don't get it, I double checked the stdlib was correctly called and present. Every other cf scripts I played with were working the same way called standalone or embeded in promises.cf.

Anyway, the goal is achieved, the only needed packages are installed.

This was weird.

--
Nicolas Ecarnot