CODEWITHSUNDEEP
macososx-lionmacports
esengineer
esengineer

Reputation: 9918

Creating Macports port which doesn't need installation, no dependency, only extract

Goal

I am trying to create a port (Macports) for an open source tool based on Eclipse which doesn't need installation, in other words, it's just "extract and use" case. Users can download the tool from the official project site and use just like that. So there is no DESTROOT variable set.

Since many Mac users got used to the convenience of Macports, I would like to add the tool there, so that users could instantly install or uninstall the tool.

** Important notice: once users start the tool, it creates "/workspace" directory in the same place the tool was installed to keep users' preferences, settings, and other necessary files. So, when users starts the tool, the program should have access to write in the same directory it was installed. The current version of the tool doesn't provide a way to choose the workspace location.

Problem

How should I organize the Portfile?

I have set the following configurations where I tell Macports to not use configure, build, and destroot phases.

set cm_workspace    /workspace

universal_variant   no

use_configure       no

supported_archs     noarch

post-extract {
    file mkdir ${worksrcpath}${cm_workspace}
    destroot.keepdirs-append  ${worksrcpath}${cm_workspace}
}

build {}

destroot {}

As I understand,

But I keep getting errors.

--->  Extracting cubridmanager
--->  Configuring cubridmanager
--->  Building cubridmanager
--->  Staging cubridmanager into destroot
Error: No files have been installed in the destroot directory!
Error: Please make sure that this software supports 'make install DESTDIR=${destroot}' or implement an alternative destroot mechanism in the Portfile.
Error: Files might have been installed directly into your system, check before proceeding.
Error: Target org.macports.destroot returned: Staging cubridmanager into destroot failed
Log for cubridmanager is at: /opt/local/var/macports/logs/_Users_nbp_macports_databases_cubridmanager/cubridmanager/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

I want to contribute to that open source community, but I can't pass this step.

Upvotes: 0

Views: 718

Answers (2)

raimue
raimue

Reputation: 4351

You misunderstood the phases, the usual workflow is as follows:

  1. extract untars the downloaded file
  2. patch applies any local patches
  3. configure runs ./configure
  4. build runs make
  5. destroot runs make install DESTDIR=${destroot}
  6. install packs the file in the destroot area into an archive
  7. activate moves the files into ${prefix}

So, in your case, you don't need steps 2, 3 and 4. But you still need to copy the files to the destroot area in step 5, the destroot phase. Otherwise MacPorts does not know which files it is supposed to install.

supported_archs     noarch
use_configure no

build {}
destroot {
    copy ${worksrcpath} ${destroot}${prefix}/some/path
}

Note that MacPorts does discourage installing files outside the prefix directory, as the installation is meant to be self-contained. The path /workspace sounds like a pretty bad idea. Rather, you should use a path inside the users home directory to save any data as otherwise this cannot be used on a computer with multiple user accounts. Of course, the actual executable files can reside in the MacPorts prefix.

Normally, UNIX software separates binaries, libraries and shared data in /usr (or in the MacPorts case,/opt/local) from user-specific data in the home directory. If your tool does not follow this convention, this needs to be fixed by the developers first.

Upvotes: 4

mmmmmm
mmmmmm

Reputation: 32626

I don't think that tool fits with macports for related reasons

All files from macports should be in one of the supported directories i.e. destroot and ending up in /opt/local
The project tries to write to sub directories which is not good here
The directories written to bu macports can only be written to by the user macports so as to minimize the ability to affect the build and run environment.
In a multiuser system who owns the directory to write to? e.g. macports are installed as user macports and are run as someone else - Also if there are more than one normal user who writes to the directory?

I think you need to patch the tool so that it is passed a directory to create the workspace in when a normal user runs it but the tool is install as ownwd by macports in /opt/local/bin

Upvotes: 1

Related Questions