pureftpd creates files outside of prefix

[Ryan Schmidt]

On Oct 10, 2009, at 03:14, Scott Haneda wrote:

> On Oct 9, 2009, at 3:44 PM, Ryan Schmidt wrote:
>
>> On Oct 9, 2009, at 04:04, Scott Haneda wrote:
>>
>>> That path is hard coded, I believe there would need to be a patch  
>>> made for the portfile to change that to that of ${prefix} in front  
>>> of it?
>>
>> Basically yes. I mean you may need to patch these to include  
>> @PREFIX@" where you want the prefix, and then later reinplace  
>> @PREFIX@ with the real value of ${prefix}.
>
> Why would I patch them and then reinplace, would the patch not  
> suffice?  Or is this is little of a chicken and an egg case?

The patch file is a static text file, but the user can use any prefix  
they like at installation time. Therefore, in your static patch file,  
you put a known marker (like "@PREFIX@") into the files where you want  
the prefix to be. Then you use reinplace in the portfile to replace  
that known marker with whatever the prefix is on the user's machine  
(the ${prefix} variable).


>>> But this may just be the ftpwho command, and where it looks.  I  
>>> can not find solid reference to where the actual creation of the  
>>> scoreboard directory happens at.
>>>
>>> The man pages, make multiple references to non ${prefix} based  
>>> locations.  I suppose those need cleaning as well?
>>
>> Good idea.
>
> Can you give me a little pointer on how man pages work, they seem to  
> be 'compiled' to a degree as well, as the files are not entirely  
> readable as they stand.  I assume there is a more human readable  
> format of the man page somewhere, but all I find is a a set of files  
> that are in some machine format.

man pages are written in the "groff" syntax, and are usually gzip- 
compressed as well. (MacPorts automatically compresses all manpages  
after the destroot phase.) The "man" command decompresses manpages and  
compiles them into displayable form using the troff command on the  
fly. I have not particularly learned the groff syntax, but as long as  
all you're doing is changing one path to another, they're pretty easy  
to edit.


> I certainly can reinplace these, but if there is an ideal way, I  
> would prefer to learn that.

Patch the files to contain @PREFIX@, then reinplace that with $ 
{prefix}, as above.


>>> Curious, is the correct procedure to have arbitrary paths that  
>>> people may want to change be a configure option, Or is it unique  
>>> to Mac Ports, and just reinplace the files carefully?
>>
>> Hardcoded paths don't seem like a great development decision to  
>> have made, but it's up to the developers of the software. If that's  
>> what they decided, then we can just patch it to make those paths  
>> match what we want in MacPorts.
>
> I am trying to reach out.  I have found one developer on twitter,  
> and gotten one reply, though it is not looking promising.  I think  
> my best bet may be to patch the source and submit it for suggested  
> inclusion.  That may gain their attention.
>
> If not, massaging it around in MP is fine, it just seems like there  
> is so much potential for breakage on updates.

If there is breakage on updates, you will immediately learn of it by  
virtue of the fact that the existing patch will fail to apply to the  
new source. You can then investigate how the source has changed so  
that you can update the patch so it works again.


> If a man page says "look for the pid file in /path/foo/app.pid and  
> there is a configure argument for setting the pid path, in general,  
> do most apps on build alter the man path to reflect that?

In general, man pages should probably describe the paths the software  
would use by default. (Users probably understand that if paths are  
configurable, then the documentation will not reflect such  
customizations.)

It would be a good idea for ports to patch related man pages so that  
they describe any changes the portfile author has made in the port. I  
expect many ports do not do this out of laziness or forgetfulness, but  
ideally they should.


> In general, is the best approach to try to figure out what your  
> paths are going to be, and provide them as configure arguments?

You're talking about a best practice for software developers? I don't  
know, it probably depends on the software.

Some paths are so common that they need no end user configuration. As  
you say below, /tmp is quite common. Conceivably an operating system  
could have its temporary directory in a different place. On Mac OS X  
for example, /tmp works, but it's really a symlink to /private/tmp,  
and for some reason there's a second temporary directory at /var/tmp,  
where /var is really a symlink to /private/var. If there exists  
another OS where there is no /tmp at all, then a program could add  
logic to its configure script to detect that OS and use an appropriate  
alternate temporary directory. There are other paths (like the  
installation prefix itself) which are useful for a packager (like a  
MacPorts maintainer) to set at compile time but which an end user  
probably doesn't need to be concerned with.

Other kinds of paths might be very relevant to the end user and would  
be better configured in a config file, alterable after installation  
time. For example, in apache2, you can specify where your web files  
live by editing httpd.conf; it would be rather restrictive to only be  
able to set that kind of thing at compile time as a configure argument.

For some software, the only way to change paths might be to edit the  
source code directly. This might be more likely in software that has  
not yet matured, or is small, or is developed by one or few  
individuals, etc.


> What is the MP suggested method to deal with very well known  
> libraries/binaries etc to the OS.  For example, pureftpd uses /dev/ 
> urandom, am I supposed to make a dependency to urandom, assuming  
> there is a port for it, then alter the source to point to urandom  
> within ${prefix}?

/dev/urandom is not a software program; it is a device. Programs that  
want some quantity of random bytes obtain these by reading from /dev/ 
urandom.

[1] http://en.wikipedia.org/wiki/Device_file_system

Not all operating systems have /dev/urandom. (Some instead have only / 
dev/random, for example.) But you can rely on /dev/urandom existing on  
Mac OS X.


> Where do you draw the line in very well known things the OS  
> provides.  Maybe the app needs use of /tmp, I am not aware of MP  
> supporting something like /tmp, so I assume it is safe to work  
> outside of ${prefix} in those cases?  If there is a doc on this, it  
> will suffice, not looking to have you teach me too much, just point  
> me along.

You can rely on /tmp existing on Mac OS X. Software that needs to  
write temporary files should feel free to use /tmp.

Attempting to create files there during any portfile phase might  
result in a warning if you use trace mode. But trace mode doesn't  
always work in all situations and can give false positives anyway.

If you need to create a temporary file or directory in a portfile  
phase, the procedures mktemp and mkdtemp exist for this purpose. They  
are used in a few places in MacPorts base and by a few ports, so you  
can find examples of their use.


> I do not feel comfortable patching this app exclusively on my own.   
> It does work now, and the issues I am bringing up do not seem to  
> cause any harm it the app working.  That being said, I would like to  
> see it cleaned up.  If I make the changes, can someone here offer to  
> validate my work?  I would love to put in the effort to fix these  
> issues, however, if there is no one that can check my work, I can  
> not in good faith submit it back to ports as I very well may be  
> releasing a buggy piece of junk.
>
> I would take notes on the changes I did, and submit them with the  
> portfile, so whoever is looking over my shoulder, would be able to  
> pretty easily see what I was thinking.


My reviews of portfiles often just consist of verifying they install,  
do not produce mtree warnings, do not link with libraries they don't  
declare dependencies on, that they're UsingTheRightCompiler, that  
livecheck works, that the universal variant works, etc. Usually just a  
subset of those unless I'm feeling particularly ambitious. But I  
seldom check that the software being ported works properly, because I  
would seldom have the expertise needed to do so. For example, I  
haven't ever set up an ftp server, so trying to figure out how to set  
up pureftpd and verify it works correctly would be much more effort  
than I would be willing to put in. Since you're interested in the  
software and presumably use it, you may be the best one to verify it  
works. And of course, if we commit it and it's broken in some way, I'm  
sure other users will notice and submit bug reports, and we can fix it  
then. This is not to say we shouldn't carefully test things before  
committing, but there's a limit to how thorough we need to be. :)