UNIX plugin appears not to set permissions for copyDirectory

[sverhagen]

Hi, I'm using the following configuration for creating a Debian assembly with the UNIX plugin:

(unix-maven-plugin:package-deb)

            <copyDirectory>
              <fileAttributes>
                <user>root</user>
                <group>root</group>
                <mode>0755</mode>
              </fileAttributes>
              <from>${project.build.directory}/${finalName}</from>
              <includes>
                <include>**.sh</include>
              </includes>
              <to>/opt/pkg-${artifactId}</to>
            </copyDirectory>

The .sh files are nicely there, though in rw-r--r-- permissions (both in the build directory and in the .deb package). Am I doing something wrong, or is this a bug? I tried looking in the code (a lot!), but I can't figure out where these permissions are supposed to be applied while writing these files to the build directory.

As a matter of fact, a quick tests indicates that I'm suffering the same problem when doing package-rpm.

I used today's trunk/HEAD version (r10633).

Thanks already for any assistance!

[Trygve Laugstøl]

Hi

Sorry for the late answer, been very busy lately.

sverhagen wrote:

> Hi, I'm using the following configuration for creating a Debian assembly with
> the UNIX plugin:
>
> (unix-maven-plugin:package-deb)
>
>             <copyDirectory>
>               <fileAttributes>
>                 <user>root</user>
>                 <group>root</group>
>                 <mode>0755</mode>
>               </fileAttributes>
>               <from>${project.build.directory}/${finalName}</from>
>               <includes>
>                 <include>**.sh</include>
>               </includes>
>               <to>/opt/pkg-${artifactId}</to>
>             </copyDirectory>
>
> The .sh files are nicely there, though in rw-r--r-- permissions (both in the
> build directory and in the .deb package). Am I doing something wrong, or is
> this a bug? I tried looking in the code (a lot!), but I can't figure out
> where these permissions are supposed to be applied while writing these files
> to the build directory.

That's a 'feature' of how the dpkg tools work. The plan is to implement
the dpkg support in pure Java giving us the ability to control it as we
want.

What people do today that create debs is to run a postinstall script to
adjust the permissions.

> As a matter of fact, a quick tests indicates that I'm suffering the same
> problem when doing package-rpm.

That should work as the permissions are controlled from the spec file.

> I used today's trunk/HEAD version (r10633).
>
> Thanks already for any assistance!

--
Trygve

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[sverhagen]

Trygve Laugstøl wrote:

That's a 'feature' of how the dpkg tools work. The plan is to implement
the dpkg support in pure Java giving us the ability to control it as we
want.

Thanks for your response. I'm getting the impression that you're misunderstanding me. I'm not complaining about what dpkg does. As a matter of fact, I have verified that when I put files with certain permissions (or even ownerships) into dpkg, these are retained in the Debian output package. Instead I'm talking about how the plugin assembles these files into its staging directory.

[Trygve Laugstøl]

sverhagen wrote:

>
> Trygve Laugstøl wrote:
>> That's a 'feature' of how the dpkg tools work. The plan is to implement
>> the dpkg support in pure Java giving us the ability to control it as we
>> want.
>>
>
> Thanks for your response. I'm getting the impression that you're
> misunderstanding me. I'm not complaining about what dpkg does. As a matter
> of fact, I have verified that when I put files with certain permissions (or
> even ownerships) into dpkg, these are retained in the Debian output package.
> Instead I'm talking about how the plugin assembles these files into its
> staging directory.

I'll have to take a closer look, but setting permissions will require
the plugin to do exec's to chmod which I've tried to avoid because I'd
like to do it in all Java for both portability and not least speed.

--
Trygve


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[sverhagen]

Trygve Laugstøl wrote:

I'll have to take a closer look, but setting permissions will require
the plugin to do exec's to chmod which I've tried to avoid because I'd
like to do it in all Java for both portability and not least speed.

All good and well, but was it not you who wrote the following in the plugin's handbook?

The Unix Maven Plugin is meant to fill in the gap between creating platform independent applications and reality

If you're gonna leave it up to the maintainer scripts in the Debian package to correct the permissions, you're not really benefiting from what dpkg can do for you. Also, when you'd run Lintian for your Debian package, it'll complain a lot. I've actually made piece with having to do this build on a Linux machine. The portability of the output files that is being the future of this plugin is much more important to me. It'll give me the confidence that I can switch from Debian to Red Hat whenever I want.

As a matter of fact, while I'm sharing opinions anyway, I think that the Maven assembly plugin is already doing a great job at the things you're still only scratching the surface with. It can already prepare everything with the right permissions etc. It'd have much more liked for the Unix plugin to focus on the packaging, not the assembling. I.e. your plugin is trying to do much more than just what it should be good at: packaging for the target platforms.

[Trygve Laugstøl]

sverhagen wrote:

>
> Trygve Laugstøl wrote:
>> I'll have to take a closer look, but setting permissions will require
>> the plugin to do exec's to chmod which I've tried to avoid because I'd
>> like to do it in all Java for both portability and not least speed.
>>
>
> All good and well, but was it not you who wrote the following in the
> plugin's handbook?
>
>
>
>> The Unix Maven Plugin is meant to fill in the gap between creating
>> platform independent applications and reality
>>
>
> If you're gonna leave it up to the maintainer scripts in the Debian package
> to correct the permissions, you're not really benefiting from what dpkg can
> do for you. Also, when you'd run Lintian for your Debian package, it'll
> complain a lot. I've actually made piece with having to do this build on a
> Linux machine. The portability of the output files that is being the future
> of this plugin is much more important to me. It'll give me the confidence
> that I can switch from Debian to Red Hat whenever I want.

I'm not going to leave it up to the scripts, but it is just not complete
yet. It is in alpha for a reason.

Even if I've tried to follow a pragmatic approach when writing the
plugin it has been a huge effort and there are lots of stuff to do
before it is complete.

> As a matter of fact, while I'm sharing opinions anyway, I think that the
> Maven assembly plugin is already doing a great job at the things you're
> still only scratching the surface with. It can already prepare everything
> with the right permissions etc. It'd have much more liked for the Unix
> plugin to focus on the packaging, not the assembling. I.e. your plugin is
> trying to do much more than just what it should be good at: packaging for
> the target platforms.

Well, I don't share your opinion on the assmebly plugin. I find it very
verbose to configure (so verbose that it is hard maintaining the files),
slow and anywhere from complete. Try to move to corner cases of the
plugin and you'll find a big can of bugs.

It can not prepare stuff with permissions (no support for changing
owner/user).

A couple of major reasons for implementing parts of the assembly plugin:

  1) I can stream files directly from the repository to disk. In the
future it will stream directly into the generated package if the format
support that (deb, rpm and sysv pkg does)
  2) I can pick out files inside a file or an artifact in the repo
directly without going through a major XML hassle of downloading files
with the dependency plugin and using the assembly to pack stuff back up.
  3) it was quite easy, commons-vfs does all the heavy lifting.
  4) The integration and error messages that I can provide makes the
Unix plugin *much* easier to use than the assembly plugin

I think there still are ITs in the Solaris plugin that uses the assembly
plugin to illustrate the amount of stuff that has to be done to do
smaller stuff.

I did start using the assembly plugin and I implemented the support for
setting permissions on aseemblies with the "dir" packaging, but it was
too complicated designed that I could bother to fix all of it. Hopefully
once the features in the Unix plugin are complete the code can move back
to the assembly plugin where it could/should be.

--
Trygve


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email