pureftpd creates files outside of prefix

[Scott Haneda]

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?

>> 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.

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

>> 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.

>> I will do my best on this one, but it may be out of my league.  It  
>> is currently nomaintainer, so I could take it over, but will need a  
>> little handholding I suspect.


A few general questions, keeping in mind my newness to this.

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, is the best approach to try to figure out what your paths  
are going to be, and provide them as configure arguments?

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}?  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.

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.

Thanks.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *