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

[Daniel J. Luke]

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.

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

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

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

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

--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080430/19ec9dfd/PGP.bin