YumRpm module

[Charles Scott]

I've been reviewing the YumRpm module which appears to use the basic rpm utility (i.e. extract command)

In reviewing past e-mails to us (specifically Johnny), there has been interest in supporting the execution of the yum utility instead.....

Is there significant interest in the calling of yum and using its inherent behavior of handling rpm dependencies? It seems that the current implementation of YumRpm and its use of the rpm -i/-u command may be misleading here?

[Alex-SF]

I agree it is misleading to call it YumRpm and it not use the yum
command for install.

[Moses Lei]

Are you sure it wasn't using yum for extract? I thought it was using rpm for remove for some reason, but yum to install.

Moses

--
Moses Lei
[ Professional Services | DTO Solutions, Inc. ]
[ office: 323.654.6944 | mobile: 703.901.5969 | e-mail: ml...@dtosolutions.com | aim/gtalk: ml...@controltier.com | yahoo: moseslei ]

--
You received this message because you are subscribed to the Google Groups "ControlTier" group.
To post to this group, send email to contr...@googlegroups.com
To unsubscribe from this group, send email to controltier...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/controltier?hl=en
http://wiki.controltier.org

[Charles Scott]

there are no commands implemented in YumRpm, they are all inherited from its parent type (Rpm):

[dnbiadm@netserver YumRpm]$ svn cat  https://moduleforge.svn.sourceforge.net/svnroot/moduleforge/controltier/branches/controltier-3-4-support/elements/modules/YumRpm/type.xml |tail -15

              <typereference name="RpmAutoreq"/>

            </singletontypes>

          </dependency-constraint>

      </constraints>

      

      <command-settings>

        <notification notify="false"/>

        <template-directory></template-directory>

        <dependency-view parents="false" children="true" proximity="1"/>

        <logger name="YumRpm"/>

      </command-settings>   

      <commands>

    </commands>   

  </type>

</types>

[Johnny Costello]

I actually am not using any rpm command at all. The modules now are
pure Yum related. I had separated this into two modules do to the
nature of yum install. There was simply no way to have a yum package
not install packages that were not controlled by change dependencies
and install only the packages that were controlled by change
dependencies. So I had to break up the Yum module into tow modules.
ApplicationYum and PlatformYum. These modules are completely yum
commands. Even since I fixed the last bug with the modules they have
been working great and I can reliably use them. You use ApplicationYum
if you want packages that are controlled by change dependencies and
PlatformYum for the Platform Applications that you rarely change and
declare in your object. I can resubmit these modules to you like. I
dont think they have made it into elements yet. I say remove YumRpm
all together.

-JC

[Charles Scott]

Hi Johnny, I retrieved your submission sent a while back, (Application and Platform) and have thought about them in more detail.....

The following I am considering in a client library (subtype, which could be promoted to elements)

Package Object attributes:

name:  required

package-version: optional

package-release:  requires package-version: optional 

from the yum man page with respect to package name, version, and release we have these possibilities as arguments to the yum install command:

name

name-ver

name-ver-rel

optional [.arch] would be part of the name or name-ver-release also as specified in yum man page

given a package object and the above name/package-version/package-release package attribute combinations, the extract behavior could be:

name

-> yum -y install <name>

name +

package-version 

-> yum -y install <name>-<package-version>

name +

package-version +

package-release

-> yum -y install <name>-<package-version>-<package-release>

where optional arch is implicit in <name> or <package-release>

[Charles Scott]

Apparently I am mistaken in the behavior or YumRpm, there is a package-extract-script defined which I will review more closely!

and implemented in the sneaky bin/extract.xml file

[Moses Lei]

This is weird. I distinctly remember working with Noah on MediaWiki and using YumRpm, and it did call yum at that point.

Moses

--
Moses Lei
[ Professional Services | DTO Solutions, Inc. ]
[ office: 323.654.6944 | mobile: 703.901.5969 | e-mail: ml...@dtosolutions.com | aim/gtalk: ml...@controltier.com | yahoo: moseslei ]

[Johnny Costello]

In my dealings with yum and deployment it is pretty important to
install exactly what you mean to install. Especially since my workflow
depends on checking what version against what you want to install.
That way i can roll back, reinstall or move forward. That is why I am
explicit in saying what I am installing and making sure people declare
everything.

Not sure what version of these modules you have. Here is what I am
currently using.

-JC

[Johnny Costello]

I really think YumRpm can go away. it was very basic and did not
really do anything. It was one of my first attempts at creating a
module. :)

-JC

[Moses Lei]

I agree with the basic concept of "Application" and "Platform" packages, but I don't like the naming. We name our types after kinds of objects, and there's no such thing as a "Yum". If we want to keep the naming convention we've stuck with-- naming subtypes as a subset of their parent-- we should call these things ...YumRpm. If YumRpm itself is a misnomer, perhaps we should name it something called "YumArtifact" but certainly not just "Yum". It seems to me that App and Platform are arbitrary too... for example, Apache might be considered a platform component but you might still want to make sure that a specific version for it is installed.

I totally agree with Chuck that the functionality can all be encapsulated in one type. The fact that we need subtypes in order for Change-Dependencies to function efficiently is really a problem with Change-Dependencies' inflexibility, not really a reason to make multiple discrete types. As an interim solution it seems like it would be okay to have trivial subtypes that just set flags, much as "war" and "PackedWar" are equivalent except for their unpacking behavior.

I think we need to do some serious research/testing before we release with an improved version of yum integration. Johnny, I'm sure these things work for you but we need to make sure that your implementation doesn't have inflexibilities that will not apply generally. From what I've seen of your code I think there are at least a few places where those kinds of issues exist.

Moses

--
Moses Lei
[ Professional Services | DTO Solutions, Inc. ]
[ office: 323.654.6944 | mobile: 703.901.5969 | e-mail: ml...@dtosolutions.com | aim/gtalk: ml...@controltier.com | yahoo: moseslei ]

[Johnny Costello]

Agreed Moses. Please look at where things are inflexible. I think i
have changed things up some in the latest incarnation to make things
better. I don't really like the names as well but it was what i can up
with. Feel free to change them to something else. Maybe Application
and Content. A Content Package is usually what you want controlled
anyways.

Yum itself was a challenge to work with since it behaves differently
than other packages. It really is a "fake" package. In reality we are
calling a process to install a package that resides some where else.
It had some real limitations to it as well if you were working with it
out of the box. There are ways to do the package install removal
workflow differently, but none that work without add-ins. If only yum
could by default roll back forward or reinstall. Only way to do that
was to use a add-on which is very buggy.

-JC