Skip to content

Conversation

@filbranden
Copy link
Member

These are the two last pending items for the XML entities with the paths when generating the man pages.

@zonque @martinpitt

I wanted to also cc Biebl but couldn't find him on GitHub, will send him an e-mail instead...

Cheers,
Filipe

zonque and others added 2 commits June 2, 2015 07:54
Replace some /usr/lib occurences in man/ with &rootprefix;/lib.
Strip trailing slashes from options such as --with-rootprefix, so that building
with rootprefix="/" results in paths like "/lib" instead of "//lib".

Also handle paths such as "/usr/" gracefully.

Use m4/ax_normalize_path.m4 from the autoconf-archive project, which is now
included in our tree as per usual practices in using autoconf-archive macros.

Tested with the following configure options:
  ./configure \
        --with-rootprefix=/ \
        --with-rootlibdir=/lib64/ \
        --prefix=/usr/ \
        --libdir=/lib/ \
        --with-bashcompletiondir=/bash-completion/completions/

(The "prefix" and "libdir" are already automatically normalized by Autoconf,
this command is testing the others.)

Compared the config.log and resulting trees (in particular man pages) to
confirm double slashes were not present in the latter.

Also tested that a configuration using default options is not affected and that
`make distcheck` still works as expected.
@zonque
Copy link
Member

zonque commented Jun 2, 2015

He seems to be @mbiebl on GitHub ...

zonque added a commit that referenced this pull request Jun 2, 2015
@zonque zonque merged commit 361d5b4 into systemd:master Jun 2, 2015
@filbranden filbranden deleted the manpages_rootprefix branch June 2, 2015 16:04
@mbiebl
Copy link
Contributor

mbiebl commented Jun 3, 2015

I noticed, that this macro replaces empty paths with '.'. I think this is problematic, because up until now, we were advocating the use of --with-rootprefix= for split-usr setups (see e.g. autogen.sh). With the patch applied, this would result in rootprefix = '.' and roolibdir './lib', etc.

So this has the potential of breaking existing setups. E.g. in Debian/Ubuntu we'd have to replace --with-rootprefix= with --with-rootprefix=/ in our build scripts when updating to v221.

@filbranden
Copy link
Member Author

@mbiebl Yes you are correct. Now looking at my notes in the commit it seems that I tested it with --with-rootprefix=/ instead which does indeed produce the expected results...

I could swear that I did test it with --with-rootprefix= (empty) but it's quite possible that I only checked the generated man pages and as man/custom-entities.ent is only removed with make clean (or at some point distclean was required) it's possible that I was looking at stale results and thought it was a valid test...

Not really sure how to proceed here... Since in a way "empty" does not equal "root" in most cases... Should we update the advice to use --with-rootprefix=/ and update Debian and Ubuntu?

Or should we handle "empty" as special? In particular, should we check it for --with-rootprefix only and turn it into /? Or should we also handle that in other fields such as --prefix?

Suggestions?

@mbiebl
Copy link
Contributor

mbiebl commented Jun 3, 2015

@filbranden I think we should change the macro to not turn an empty argument into '.' at least for commands which set a prefix to not break existing usages of --with-rootprefix=

Looking at what autoconfi does:
a) ./configure --prefix= → is accepted and prefix= empty
b) ./configure --libdir= → $ ./configure --libdir
configure: error: missing argument to --libdir

I think we should do at least a) in our macro, b) would be an optional nicety. Erroring out in that case makes more sense to me then setting it to '.'. That said, I doubt any of our --with-foodir configure switches will ever be set to an empty string. So it's probably not relevant in practice.

@martinpitt what do you have think?

@martinpitt
Copy link
Contributor

IMHO defaulting to a relative path like "." for an empty argument is almost always unintended and a trap. I really don't mind adjusting our debian/rules to set the argument to "/", but we are by far not the only ones building systemd :-)

If it's hard/impractical to handle an empty value appropriately, then erroring out in configure with "no value set" or so would be a fine safeguard to avoid this trap.

Thanks @filbranden for working on this!

@zonque
Copy link
Member

zonque commented Jun 3, 2015

I fail to see any good reason for replacing "" with ".", am I missing anything? I think the best solution here is to remove that special case handling from AX_NORMALIZE_PATH(). After all, all we wanted to achieve is removing trailing slashes.

@filbranden
Copy link
Member Author

So whatever we do, I think we should not modify the definition of AX_NORMALIZE_PATH on our tree, since we're essentially downstream from autoconf-archive here...

I think the rationale to transforming (empty) to "." is that that's what it means for example when you have an empty entry in variables like $PATH, for instance PATH=/bin::/sbin means look in /bin first, then if it's not there look in the current directory, otherwise in /sbin, exactly the same as PATH=/bin:.:/sbin.

Though I see the point that using "." doesn't really make a lot of sense for paths passed to ./configure, after all we mostly want absolute paths most of the time. And your point that --prefix= already defaults to / is another good argument in that sense.

So, my proposal is:

  1. Open a GitHub issue to track this.
  2. Add a workaround in configure.ac to check for an empty ${with_rootprefix} and replace it with a / right before calling AX_NORMALIZE_PATH on it and refer to the GitHub issue as it's a temporary workaround.
  3. Rework the AX_NORMALIZE_PATH macro and send it upstream to autoconf-archive project. My suggestion is to add an optional third argument to it to indicate what to do with an empty string and default that to "." if that's not passed around, so we can use something like AX_NORMALIZE_PATH(${with_rootprefix},,/) in our code.

Does that sound good? I'll start working on steps 1 and 2 right now and send you another PR.

Cheers,
Filipe

mischief added a commit to mischief/systemd that referenced this pull request Mar 22, 2016
backporting journal changes from master to v229
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants