HOWTO: Get started, gain macports-foo, make bad first impression

[Ryan Schmidt]

On Apr 30, 2008, at 1:46 PM, Daniel J. Luke wrote:

> On Apr 30, 2008, at 1:23 PM, Jay Levitt wrote:
>
>> But I have absolutely no idea how to go about incorporating  
>> others' fixes, or trying and submitting my own.  And the FAQ  
>> doesn't have a "how can I get involved" section.  Any tips/pointers?
>
> Have you read the guide? (http://guide.macports.org)
>
>> For example:  I just tried installing jigdo.  That port relies on  
>> libwww, which is currently broken for some configurations.  Ticket  
>> #12851 (http://trac.macosforge.org/projects/macports/ticket/12851)  
>> fixes this, and it refers to changeset r34520, a patch to trunk/ 
>> dports/www/libwww/Portfile.
>
> That ticket is marked as fixed and checked in in r34520, so you  
> just need to do 'port selfupdate' or 'port sync' to make sure you  
> have the latest Portfile and you'll already have that fix.

Right. Although the repository URL to the dports tree contains  
"trunk", there are no branches of dports. The one in "trunk" is the  
only copy, and it's the one all installations of MacPorts sync with.  
(Well, they sync with an rsync server which mirrors the dports tree  
from trunk, with up to 30 minutes delay.)

>> 1. What's the right way for an end-user-slash-developer to  
>> incorporate bug fixes into my local copy?

For bugs which have been fixed, simply "sudo port selfupdate" or  
"sudo port sync" to retrieve the changed portfile. The portindex is  
only regenerated every 12 hours so if e.g. a port version has been  
updated, you might not see that change in "port outdated" for up to  
12 hours.

For bugs which have not yet been fixed in the repository, do what  
Daniel said:

> it really depends on the workflow you want.
>
> One way would be to set up a local portfile repository and put your  
> fixes in there while you test them (the guide describes how to do  
> this), another way would be to check out a copy of the portfiles  
> from svn and point Macports to those portfiles.
>
> You can even do what you did earlier and modify the portfile that  
> macports has already put on your machine (although the next  
> selfupdate or sync you do will get rid of your local changes, then)
>
>> 2. What's the best way for me to contribute when I find problems  
>> like this?
>
> File bugs in trac and assign (or CC) them to the maintainer of the  
> port.
>
> It's especially helpful if you've figured out how to fix it and  
> have a patch that you can attach to the bug.
>
> If it's for a port that currently doesn't have a maintainer, it  
> would be great if you would be willing to maintain the port!
>
>> 4. I saw a discussion about parallel builds, and how you can't  
>> enable them by default.  Does "port" send any phone-home info  
>> about build failures/successes?
>
> nope
>
>> Is that under consideration?
>
> I don't think anyone is working on anything like that, there was  
> some discussion in the past, with the takeaway that it would need  
> to be off by default and optionally opt-in if it were something  
> that was even going to be added.
>
>> It seems to me that the best solution for this, and for any  
>> breaking change, would be to allow end users to opt-in and become  
>> part of the macports "build farm".  Instead of a yes/no flag for  
>> parallel builds, add a third state: experimental.  Experimental  
>> would build everything in parallel, run the unit tests,
>
> Not ever port has tests available from the upstream, and not every  
> end user has a 'clean' build environment (so this would also  
> require either getting chroot/trace mode/whatever build environment  
> working well enough to make it the default, and probably storing  
> state other than OK/Not OK - since ports could build fine but not  
> work, and it would be difficult to test every port that doesn't  
> already have a comprehensive test suite).

The other problem with parallel builds is that they are not identical  
each time you run them. The build may succeed 3 times, then fail the  
4th. I personally haven't had the time to try to build each of my  
ports several times with parallel build on to see if they repeatably  
build correctly.


>> and report back to macosforge.  If we see it working on enough  
>> "supported platforms", we could flip the Big Switch and move that  
>> to the stable distribution.
>
> There is currently no stable/unstable distinction for portfiles.
>
> I think it would be nice to have something like this, where we have  
> some state associated with each port that would give an indication  
> of what systems the port has been successfully built on (and maybe  
> eventually where it works correctly). If we combined it with some  
> way for multiple versions of the portfile to be available to the  
> end-user they could choose to install the 'newest' portfile, the  
> newest one that has been build tested on similar hardware, or an  
> older version.
>
> Of course, if we end up getting binary packages working well, we  
> might not need any of this support infrastructure.

Sounds nice to me. But how would we learn what port works on what  
OS / architecture? I had proposed last year the idea of MacPorts  
automatically sending information back to the mothership regarding  
what ports people had installed on what OS and what architecture,  
which could be used to determine which ports actually work, and could  
also show port popularity. I thought this would make for an  
interesting front-page www.macports.org display, showing the most  
popular ports. But several people didn't want MacPorts reporting this  
information:

http://lists.macosforge.org/pipermail/macports-dev/2007-May/001604.html

Maybe we should revisit this topic, though like you say, if we get  
binary packages, then we don't need build success/failure statistics  
from each user, but only from the build servers.


>> In fact, now that I think about it, this could help a lot of the  
>> problems I've run into, all of which appear to be "no longer works  
>> on the latest OS/hardware/whatever but the port maintainer doesn't  
>> run that".
>>
>> Thoughts?
>
> If you've got the time, it would be great if you would check out  
> the macports code, and try to get (at least some of) your ideas  
> working.