FAQ
Hi all,

I have a nasty feeling I'm about to open a can of worms, but here goes
anyway...

I'm writing a module for OSX which will allow me to install
applications ('.app', both zipped and dmg'd, and '.mpkg's) using a
manifest, a bit like the Windows package module but without the need to
have a custom repo, just point it at the installer files - ideally I
would have called this package 'pkg', via it's __virtual__, as I'm
giving it the same interface as the other pkg modules but I noticed, on
my mac, that home-brew has already called itself 'pkg' (so my module's
called osx_pkg, instead, which I can live with). The problem I've
noticed is that macports also uses 'pkg' as its __virtual__ name so if
both home-brew and macports are installed (which I know is not
recommended but it is possible and there are reasons for desiring this,
as macports has software not in brew and vice-versa) whichever module
get loaded last wins the name game - and I'm not convinced, looking at
the loader code, that it's always guaranteed to be the same one
(depending on the order that the module filenames are listed, and
looking at -l trace when loading the modules it's not asciibetical). As
the loader does no 'a module called this is already loaded' detection,
not so much as a warning gets uttered by salt.

Soooo.... how does one resolve that 'pkg.installed' might be run by two
different package managers on the same machine as both macports and
home-brew are installed?

Is there a recommended alternative name to use for a module using the
os-native packaging methods when 'pkg' has already been hijacked by two,
competing, non-native applications? Personally, I'm surprised that
either brew or macports are using 'pkg', I would have thought 'brew' and
'port' or 'macport' would have been more appropriate given they can
co-exist and both are 3rd party installs (i.e. not the platform native
package format - which on a Mac would be a packed .app).

thanks,

Laurence

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

Search Discussions

  • Paul Traylor at Sep 11, 2014 at 4:05 pm
    You can use the providers option in the minion config to use a specific module.

    http://docs.saltstack.com/en/latest/ref/configuration/minion.html#std:conf_minion-providers

    So in your case you should be able to set it to osx_pkg. This should
    help you with a workaround until you get a better answer from someone
    else :)

    2014-09-11 8:52 GMT-07:00 laurence <laurence@entek.org.uk>:
    Hi all,

    I have a nasty feeling I'm about to open a can of worms, but here goes
    anyway...

    I'm writing a module for OSX which will allow me to install applications
    ('.app', both zipped and dmg'd, and '.mpkg's) using a manifest, a bit like
    the Windows package module but without the need to have a custom repo, just
    point it at the installer files - ideally I would have called this package
    'pkg', via it's __virtual__, as I'm giving it the same interface as the
    other pkg modules but I noticed, on my mac, that home-brew has already
    called itself 'pkg' (so my module's called osx_pkg, instead, which I can
    live with). The problem I've noticed is that macports also uses 'pkg' as
    its __virtual__ name so if both home-brew and macports are installed (which
    I know is not recommended but it is possible and there are reasons for
    desiring this, as macports has software not in brew and vice-versa)
    whichever module get loaded last wins the name game - and I'm not convinced,
    looking at the loader code, that it's always guaranteed to be the same one
    (depending on the order that the module filenames are listed, and looking at
    -l trace when loading the modules it's not asciibetical). As the loader
    does no 'a module called this is already loaded' detection, not so much as a
    warning gets uttered by salt.

    Soooo.... how does one resolve that 'pkg.installed' might be run by two
    different package managers on the same machine as both macports and
    home-brew are installed?

    Is there a recommended alternative name to use for a module using the
    os-native packaging methods when 'pkg' has already been hijacked by two,
    competing, non-native applications? Personally, I'm surprised that either
    brew or macports are using 'pkg', I would have thought 'brew' and 'port' or
    'macport' would have been more appropriate given they can co-exist and both
    are 3rd party installs (i.e. not the platform native package format - which
    on a Mac would be a packed .app).

    thanks,

    Laurence

    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laurence at Sep 12, 2014 at 9:35 am

    On 2014-09-11 17:05, Paul Traylor wrote:
    You can use the providers option in the minion config to use a
    specific module.


    http://docs.saltstack.com/en/latest/ref/configuration/minion.html#std:conf_minion-providers

    So in your case you should be able to set it to osx_pkg. This should
    help you with a workaround until you get a better answer from someone
    else :)
    Thanks Paul, that helps me to work on my development.

    I think I'll do some experimenting with the other issue (how to manage
    both brew and macports with Salt) and might raise that as an issue on
    github - I think that is probably a more appropriate place to have a
    discussion of how (or if!) that particular can or worms can be
    addressed.

    Ta,

    Laurence

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedSep 11, '14 at 3:52p
activeSep 12, '14 at 9:35a
posts3
users2

2 users in discussion

Laurence: 2 posts Paul Traylor: 1 post

People

Translate

site design / logo © 2022 Grokbase