It is there as a reminder to help me to know what is all availble and possible.
Going to leave it in for the time being.
Would even be nicer if the was a Makefile.template that some of these hard to find things just pre-programmed.

Hi Mat,

If I do that then the code fetching my branch starts for a wrong file:

=> wjwithagen-ceph-wip.FreeBSD.v doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/wjwithagen/ceph/tar.gz/wip.FreeBSD.v1?dummy=/wjwithagen-ceph-wip.FreeBSD.v
fetch: https://codeload.github.com/wjwithagen/ceph/tar.gz/wip.FreeBSD.v1?dummy=/wjwithagen-ceph-wip.FreeBSD.v: size of remote file is not known
wjwithagen-ceph-wip.FreeBSD.v                         9251 kB 2931 kBps 00m03s

And make really barfs at me:

make: Unclosed substitution for DISTVERSION (- missing)
make: Unknown modifier 'w'
make: Unknown modifier 'c'
make: Unclosed variable specification (expecting '}') for "DISTVERSION" (value "") modifier c

Doing it my way at least gets me the source from GitHub.

Sollution here is to define

DISTVERSION=

and leave it empty

Your "problem" goes away if you set:

DISTVERSION= git.2017-02-14

And then use a commit hash, or a tag in with the github framework.

wip.FreeBSD.v1 is not a version, it is your work branch. git.2017-02-14 is a version.

Hi Matt,

Will try the tag stuff in GitHub. And yes I do plan to sort "release" my WIP versions.
So updating the TAG and sha256 is not that large of a problem

Cool, that works.
And it is not much different from creating a branch, and the GitHub interface makes it relatively easy.

make: Unclosed substitution for DISTVERSION (- missing)
make: Unknown modifier 'w'
make: Unknown modifier 'c'
make: Unclosed variable specification (expecting '}') for "DISTVERSION" (value "") modifier c

What FreeBSD version are you using ?

Matt,

I'm testing on several versions, but everything 11.0-RELASE or up:
FreeBSD cephtest 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420

The errors are from:
FreeBSD freetest.digiware.nl 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r312623M: Sun Jan 22 19:17:33 CET 2017

I'm using it in the version string for what to fetch from github.
Perhaps with your suggestions it now better fetches what it should

This is a hairy one....
And I do not seem to be able to get this working without wierd things

I'd like to call the port ceph-devel.
the GH stuff does not like a - in its brach string, so I have called the branch to checkout wip.FreeBSD.v1.
I can tag it with just about anything we like.

What does work is setting:

DISTVERSION= wip.FreeBSD.v
DISTVERSIONSUFFIX=1

You could be right, probably a leftover from when I want the build process to fetch and update the git submodules.
Lets see what happens if I move it to FETCH

It is >= and =>

Ah, oke.
Not prefixing the path here will have the dependancy builder argue that /usr/bin/getopt is already there, and that it is a strange question to ask. So hence the /usr/local/bin prefix. But using LOCALBASE makes better sense

So how would I get a user and group named ceph set?
prefably to a fixed UID/GID

You do that with defining USERS and GROUPS, and adding the user(s) and group(s) you need to UIDs and GIDs at the root of the ports tree. But adding commented out lines is a big no.

It is a reminder that I once ran into unresolved lib with this, and I added it to install-deps.sh.
But until now the port seems to be building fine, even in poudriere. So I think it can go.

Ah,
Oke, will try. Last time I did remove this, it did not fetch my source from github.
But make still complains about unclosed veriable specification for "DISTVERSION"

It is a reminder for myself on what the grammar for these lines are.
And since Ceph is rather abundant with extra modules I would like to keep it there, so it is clear what is where.

Not quite sure what line Mat is refering to that can go?

portlint -A requires it to get ride of a warning

Sure, portlint is crappy, now, please, remove this line.

Yes, since build on that location is intrinsic on how source/cmakefiles and build tree are setup.
Another advantage is that this way the tree is equal to the development tree, and that will help debugging problem due to ports-packaging.

Ok, so, you want to build this software differently that everything else using cmake, great. Why not do the symlink the other way around so that it does everything the way the ports tree does it ?

I was expecting that.
But there is a catch-22 here.
The source of this ports-files also goes back into the ceph github-repo, and as soon as I made distinfo, anb resubmitted that to github, the SHA256 in github has changed again.

Suggestions on an easy way out are welcomed. 8D
Otherwise I'll have a github version that does not 100% match what is in net/ceph-devel.

Unless the tag you are using as the version of ceph is being moved, it does not change, ever.

If it is a branch, then, DO NOT USE A BRANCH, use a tag, or a commit hash.

Well ceph-devel is intended as shooting at a running target with the ceph-tree and my work on it.
I also intend to commit a version which is based on the original Ceph releases

I recommend that you do what lang/rust-nightly does. It tracks github, but the port always specifies a specific tag. The maintainer must periodically update the tag in SVN. This way, the build is stable. It never gets broken by surprise. For your own development builds, you can always remove the tag and set NO_CHECKSUM on the command line, but don't submit it.

The ports tree is not a moving target. We must be able to rebuild anything as it was the day it was committed. Like I said, use a commit, or a tag, not a branch.

But not with the options that it requires.
Here also the Cmake files are build to a certain expectation of the tree that does not seem to match what Mk expects.
I think I added the target because I need to run cmake ..

This is how I ended up with the wy the cmake env is used by Ceph.
Ceph expects all of its submodules in src/
and it expects build/ next to src/

And then it starts to do weird things in referencing from build to src locations.
I'm not even sure I would be able to fix that, let alone that it is not going to be accepted by the Ceph committers.

So I don't have a use for .build/, it is only there to please the Mk-infra

If you must, you can redefine the location of this directory with CONFIGURE_WRKSRC and related variables. See Mk/Uses/cmake.mk. It's better to redefine those variables than do override the pre-configure target.

I would have expected so, but I wasn't getting any parallel make.
But I do not remember if that was in poudriere or not.
And I found that poudriere has -J
So I'll take it out.

If there are empty directories that are needed, they must be created at some point, and put in pkg-plist, if the software build system does not create them, and they are needed at run-time, they should be created here.

I'll make it post-install, and pkg-plist does need them pre-made.

This is part of the hardcoded expectancies of Ceph.
And I have selected not to fight a battle with the ceph people to change that.
The selection of which config stuff to use is rather convoluted, and I did not want to waste time on that ATM.

Then the port should patch ceph, ports live in PREFIX, which is /usr/local, they do not put anything in /etc, or anywhere else. (/var is somewhat ok)

So then I should not submit the port I guess??
There is a ton of changes required to fix this, and it is not going to go in easy.
Also in the full testset. Let alone in the QA testset that Ceph also runs on all changes.
Unless I start maintaining it as a patch set, which is going to grow stale pretty soon.

What about a softlink from /etc/ceph to /usr/local/etc/ceph

IMHO this is more of a guideline than a rule. Ideally Ceph would allow its config files to live in /usr/local/etc. But there are plenty of other ports that don't, like tomcat8, X11, logrotate and even pkg. Having worked on Ceph, I know what a Herculean effort it would be to push up a change like this, and I think that it would be more valuable to get net/ceph-devel into the ports tree first. We can always make it a goal for net/ceph.

Well, consider the only place you can write is /var/ and /usr/local/, everything else is read-only from a port's point of view.

By all mean, submit the port, there are certainly people who would like it, which is what you are doing right now, but before it gets accepted, it must follow our rules.

I do not believe patching the sources to use /usr/local/etc/ceph and not /etc/ceph should be a hard thing.

I can't believe they hardcoded it everywhere, there must be some global define with it somewhere.

Mat,

You are a real software optimist. ;-)
There's about 50 lines with references to /etc/ceph in about 30 files.
So I agree that that is not a major issue.

Getting modified may not be the biggest problem, getting them accepted is.
Sure it is doable, and I'm willing to invest the time.
But I'm not going to hold my breath for this one, it is going to take quite some time.

It is part of the environment Ceph expects.
It does not make these directories when is starts for the first time

PREFIX/etc/rc.d is already created because USE_RC_SUBR is in use, so remove it from here.