ability to exclude pre-existing directories?

[ncolton]

I've come across a bit of a frustration, and I'm hoping that I just don't know how to accomplish the goal of excluding pre-existing directory structures. To illustrate the issue, if I have the following super-simplified situation of a file "init" in the root of the project, and the following POM:

<?xml version="1.0" encoding="UTF-8"?>
<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>no.t.real</groupId>
    <artifactId>demonstration</artifactId>
    <version>0.1-SNAPSHOT</version>
    <licenses>
        <license>
            <name>none</name>
        </license>
    </licenses>

    <build>
        <plugins>
            <plugin>
                <groupId>no.arktekk.unix</groupId>
                <artifactId>unix-maven-plugin</artifactId>
                <version>1.0-alpha-7-SNAPSHOT</version>
                <configuration>
                    <rpm>
                        <group>Example</group>
                    </rpm>
                    <assembly>
                        <copyFile>
                            <path>init</path>
                            <toFile>/etc/init.d/bogus</toFile>
                            <attributes>
                                <user>foo</user>
                                <group>bar</group>
                                <mode>500</mode>
                            </attributes>
                        </copyFile>
                    </assembly>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>no.arktekk.unix</groupId>
            <artifactId>unix-maven-plugin</artifactId>
            <version>1.0-alpha-7-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
    </dependencies>
</project>

When run to create an RPM, the result is the following RPM spec file:

Name: demonstration
Version: 0.1_20130212.174217
Release: 1
Summary: demonstration
License: none
Group: Example
BuildRoot: /Users/ncolton/tmp/packageTest/target/unix/root-rpm/assembly
BuildArch: noarch

%description

%files
%dir %attr(0755,root,root) /etc
%dir %attr(0755,root,root) /etc/init.d
%attr(0500,foo,bar) /etc/init.d/bogus

The desired result would be a spec file that does not have the line for /etc nor /etc/init.d as those are both pre-existing on a target system that would use RPMs. Similarly, when creating a Solaris package, I get the following prototype file:

i pkginfo=/Users/ncolton/tmp/packageTest/target/unix/root-sysvpkg/pkginfo
d none /etc ? ? ?
d none /etc/init.d 0755 nobody nogroup
f none /etc/init.d/bogus=/Users/ncolton/tmp/packageTest/init 0500 foo bar

For the prototype file, the user and group settings are more obviously conflicting as /etc/init.d should have user root and group sys. It would be preferable that, in this case, /etc/init.d also have the default values, just as /etc does.

If there is a means of causing the RPM spec to not include certains paths, and for the prototype file to have default values (? ? ?) set for certains paths, that would be a decent workaround, but I wasn't able to find such.

[ncolton]

Oh, also… would you prefer issues tracked here, or http://jira.codehaus.org/browse/MUNIX, or somewhere else?

[trygvis]

I'll take a look at the issue.

Here is fine until I move the git repository back to Codehaus.

[trygvis]

This is not possible now, but I'm sure it can be supported in one way or another.

The entries are generated as the RPM requires the root directories to be declared. IIRC it was a reason why only the root directories was declared with "?" but the rest specified. Can you suggest a better default? I guess an override would be useful anyway.

PS: You don't need the dependency on the plugin. If you want to use <packaging>rpm</packaging> you need to add <extensions>true</extensions> to the <plugin> part.

[ncolton]

I'm guessing you meant to say that the Solaris package requires the root directories be declared, as RPM mercifully handles directory creation without needing to explicitly note parent directories.

What might be "safer" is to have the default of mode/user/group as "?" (leave pre-existing values alone on target system) until encountering something specified in the assembly rules. If I specify a <to>/usr/local/man/man8/cog.8</to>, at least based on the system I'm on right now, only the files within that path should fiddled with but /usr/local/man/man8 should all be marked with triple-? in the prototype file, while a <toDir>/directoryNotOnTargetSystem</toDir> would, I think, need mode/user/group set explicitly as it doesn't exist yet on the target system(s). How to determine this programatically is not possible without additional information.

To make sure I'm not confusing things more, what I would want to see as a result of the two above 'to' tag-values is something like:

d none /usr ? ? ?
d none /usr/local ? ? ?
d none /usr/local/man ? ? ?
d none /usr/local/man/man8 ? ? ?
f none /usr/local/man/cog.8 544 someuser somegroup
d none /directoryNotOnTargetSystem 755 someuser somegroup

For the RPM side, rpm-maven-plugin appears to only write an entry for the %files section if it is defined by a mapping in the POM file. For unix-maven-plugin, I think this would translate to: If an assembly instruction such as copyfile/directory, mkdir, etc. exists, use the deepest directory path as the value to write. I'd have to play with it a bit to make sure that is the correct interpretation, and it probably won't work for other package systems…

Perhaps using a package specific setting for sysvpkg to specify where "ownership" begins and anything to the root-side of the filesystem is set to "?" and values to the right are set to either the default, or the explicit value set by a given assembly instruction. This means the behavior only kicks in if it is specified. If some smarter way is figured out later, the affect of this old setting would be less problematic to remove at that later point in time.

So for the above example paths:

<sysvpkg>
    <pathOwnership>
        <path>/directoryNotOnTargetSystem</path>
    </pathOwnership>
</sysvpkg>

An alternative, possibly smarter and safer, is to use mkdir operations to define where ownership begins. Naïvely assume that directories already exist for copy operations and have them set to ? ? ?. Directories created as the result of artifact and file extraction would use the default or explicit settings. Set attributes would obviously use the explicit values. Make directory operations would cause the directory created and all subdirectories of the created directory to use default/explicit values.

[ncolton]

You don't need the dependency on the plugin. If you want to use rpm you need to add true to the part.

What we are actually doing is creating both an RPM and a Solaris Package, so I'm avoiding setting the packaging value as they need to be built on different build slaves, as far as I know. Does specifying the extensions as true remove the need for the dependency setting?

[trygvis]

On Wed, Feb 13, 2013 at 03:36:02PM -0800, ncolton wrote:

You don't need the dependency on the plugin. If you want to use rpm you need to add true to the part.

What we are actually doing is creating both an RPM and a Solaris Package, so I'm avoiding setting the packaging value as they need to be built on different build slaves, as far as I know. Does specifying the extensions as true remove the need for the dependency setting?

Ah, I didn't know that you actually did build both kinds from a single POM.

You shouldn't need the dependency in any case.

Trygve

[trygvis]

I think your last suggestion is the one that I like the most, and the one I think I've tried to implement. Using mkdir/setAttributes is easy to do and matches semantics you would use if you where to deliver these files by hand.

I'll take a look. Thanks for your very detailed descriptions!

[ncolton]

I'm glad I wasn't just drowning you in a sea of text! =D