December 2006 - macports-dev - lists.macosforge.org

15 Feb '07

Hi all, this is my first mail here, please correct if is not the right place to post this kind of informations. The current port of postfix doesn't work well, so I did some work trying to make it ok: Attached are: - a simple patch to postfix-script so it can correctly recognise folders permissions - a patch to the portfile which: * add cyrus support (this must be done explicitely in 2.3.X) * try to compile postfix against _system_ openssl and _macports'_ sasl2 * bump postfix version to 2.3.4 There's one unresolved issue, no matter if I explicitly compile it against system or macports version of openssl, I have this warning: ------ postfix/smtp[24927]: warning: run-time library vs. compile-time header version mismatch: OpenSSL 0.9.8 may not be compatible with OpenSSL 0.9.7 ------ Which means it compiles against system version of openssl and uses macports' one at run time. As a result I can't start a tls connection with any mailserver. After installation 2 files must be deleted (I don't know which is the best way to do this in the Portfile): /opt/local/var//spool/postfix/maildrop/.turd_postfix /opt/local/var//spool/postfix/public/.turd_postfix Please let me know what do you think about this, and forgive me if something is wrong because this is my first attempt to modify a port. Gufo -- ,___, If you're not part of the solution, (9v9) you're part of the precipitate (_^((\ My site: http://gufo.dontexist.org/ -^-"-"-\\-^-- Gpg Key at: http://gufo.dontexist.org/db.asc

5 5

Naming of postgresql & related
by Jyrki Wahlstedt 23 Jan '07

23 Jan '07

Hi, I just wonder about naming postgresql, some other ports could have the same. Currently postgresql installs v.7.4.12. Then we have postgresql7 (v.7.4.13), postgresql8 (v.8.1.3) and postgresql81 (v. 8.1.4). This is a mess. I think postgresql should always be the latest, then we could, if we want, to have version-specific ports (~7, ~8, ~81). How about this? The related thing comes from the fact that the database formats between point versions of postgresql are not compatible (8.0->8.1). Is there a way to make sure that database is dumped before upgrade. Could one ask a question from the user and wait for an answer (to confirm the operation)? ! ! Jyrki Wahlstedt ! Kolmas linja 12 A 18 mob. +358-400-347 015 skype:jyrkiwahlstedt ! FI-00530 Helsinki http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386

6 7

Policy on minor port changes?
by Kevin Ballard 30 Dec '06

30 Dec '06

What's the policy on making minor, harmless portfile changes to ports you don't maintain? For example, ticket #11201 says a dependency is missing to p5-locale- gettext (namely, perl5.8). This port is maintained by yeled(a)macports.org. It would be a trivial fix to commit, but to be safe I simply reassigned the ticket to yeled(a)macports.org. However, there's no guarantee he'll actually see it. So in a case like this, should I just go ahead and commit a fix? Or is it better to wait for the maintainer to do so, even for minor fixes like this? -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

2 1

Why does darwinports developers choose the tcl/tk for darwinports project?
by Jin Hyung Park 30 Dec '06

30 Dec '06

Hello :) Today morning, I just wonder Why does darwinports developers choose the tcl/tk for darwinports project? After 2001, there are lots of languages not only tcl/tk.. are there specific reasons for choosing tcl/tk? if anyone know, could explain for me? thanks :)

9 10

port upgrade causes problems when port not installed
by Kevin Ballard 29 Dec '06

29 Dec '06

I just had an interesting problem, as detailed in ticket <http:// trac.macosforge.org/projects/macports/ticket/11200>. Can anybody tell me why port upgrade used to build first, then install the new one, then deactivate/uninstall the old, then activate the new? And why now it's always deactivating/uninstalling first before installing the new? Except, as you can see in my log, doing the upgrade without it already installed finished the aborted build, installed, then uninstalled and started trying to re-build/install again? -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

2 3

Re: Explicit vs Implicit deps [was Re: Unstated dependencies on gettext]
by Jim Mock 29 Dec '06

29 Dec '06

If it weren't for the giant pain of trying to track down all inherited dependencies for a given port (particularly ones with a pretty large list), I think I'd lean more towards the flat dependencies since we'd probably be less likely to run into breakage due to a missing dependency somewhere (helping with automation is also good). That said, I think it'd be more fun to poke myself in the eyeballs with a stick than try to track down the dependencies for a few of my ports (gtk2 and some ports that use it come to mind immediately). I guess I'm not sure which I'd choose either if I had to decide. Do we go with easier maintenance or (potentially) better reliability? Ugh. - jim On Dec 28, 2006, at 6:31 PM, Jordan K. Hubbard wrote: > This brings up an interesting(?) point that, if memory serves me > correctly, we've discussed before without resolution. > > First, I'll sum up the previous discussions with what I believe to > be the essential underlying question: Are dependencies best > described (in a complex software collection) as hierarchical or flat? > > Hierarchical has its obvious advantages: You avoid the > combinatorial explosion of dependencies that things like GNOME and > KDE would drag in to each and every KDE clock or GNOME mp3 tag > editor port and, notionally at least, you can have a much smaller > collection of ports contain the "authoritative dependency lists" > for commonly used crap and, presumably, a smaller number of things > to edit when those dependencies change. > > On the flip side, flat has other advantages: It decouples ports > from one another, particularly in a system like MacPorts where you > don't actually get full benefit from those "common ports" since > once one of them is installed, its dependency list is statically > determined at install time and ages thereafter. Even if the > Portfile gets updated to track new deps, it doesn't matter if the > user has already built and installed the port given the short- > circuiting that will then take place, avoiding the updated > Portfile. Flat also copes better with other types of dynamism in > the collection - say gettext depends on libintl for a few years, > then one day somebody realizes that gettext only needs a few > functions from libintl and would be better off implementing those > functions itself, so they do this in the next release of gettext. > The Portfile maintainer for gettext realizes this and removes the > libintl dependency. Boom, all those ports which depended on > gettext with the assumption that they'd get libintl for free now > break. Finally, a flat dep space lends itself well to automation > - if kvv ever implements something similar to DarwinBuild for > MacPorts, that mechanism will find every single port something > depends on and, presumably, update the Portfile accordingly. At > that point, the hierarchy becomes flattened anyway. > > Despite having a lot more verbiage on the subject of flat > dependencies, I don't actually have a firm preference for either - > I can still see both sides of the argument fairly clearly. > > Thoughts? > > - Jordan > > On Dec 28, 2006, at 5:28 PM, Jim Mock wrote: > >> Crap, ignore that, I had it backwards. The gettext port actually >> depends on libiconv and not the other way around. >> >> If you do come across things that link against libintl and don't >> have gettext as a dependency (whether direct or indirect), it >> should probably be added as one. >> >> - jim >> >> >> On Dec 28, 2006, at 5:24 PM, Jim Mock wrote: >> >>> On Dec 28, 2006, at 5:00 PM, Kevin Ballard wrote: >>>> After having updated gettext, I'm finding a number of ports that >>>> are linking against libintl (provided by gettext) but don't >>>> declare a dependency on gettext. >>>> >>>> For example, gsed links against libiconv, but doesn't declare a >>>> dependency on gettext. >>> >>> This is because libiconv depends on gettext so, if you've got >>> libiconv, you've got gettext. >>> >>>> The question I have is, would some of these ports have worked if >>>> gettext wasn't installed, but just happen to link against >>>> libintl for extra functionality if it's there? >>> >>> It should because something it depends on depends on gettext >>> (whether it be libiconv or something else). >>> >>> - jim >>> >>> >>> >>> _______________________________________________ >>> macports-dev mailing list >>> macports-dev(a)lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo/macports-dev >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev(a)lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev >

1 0

Re: Explicit vs Implicit deps [was Re: Unstated dependencies on gettext]
by Kevin Ballard 29 Dec '06

29 Dec '06

I would say if a port depends directly on another port, it should list that dependency, even if one of its other dependencies also has this. As you pointed out, this is more robust to change. And the notational trick you mentioned for things like GNOME or KDE would also help with the dependency explosion problem. But anything a port doesn't use explicitly probably shouldn't be listed. For example, glib2 depends on gettext. So if my port Barfoo uses glib2, it indirectly depends on gettext, but if it doesn't actually use anything from gettext directly, it should leave that dependency to get resolved hierarchically via glib2. So basically, I'm in favor of a flatter hierarchy. But, were I given the power to decide, I'd still be hesitant about committing to this, because I can see the cons of flat and benefits of hierarchical too. On Dec 28, 2006, at 9:31 PM, Jordan K. Hubbard wrote: > This brings up an interesting(?) point that, if memory serves me > correctly, we've discussed before without resolution. > > First, I'll sum up the previous discussions with what I believe to > be the essential underlying question: Are dependencies best > described (in a complex software collection) as hierarchical or flat? > > Hierarchical has its obvious advantages: You avoid the > combinatorial explosion of dependencies that things like GNOME and > KDE would drag in to each and every KDE clock or GNOME mp3 tag > editor port and, notionally at least, you can have a much smaller > collection of ports contain the "authoritative dependency lists" > for commonly used crap and, presumably, a smaller number of things > to edit when those dependencies change. > > On the flip side, flat has other advantages: It decouples ports > from one another, particularly in a system like MacPorts where you > don't actually get full benefit from those "common ports" since > once one of them is installed, its dependency list is statically > determined at install time and ages thereafter. Even if the > Portfile gets updated to track new deps, it doesn't matter if the > user has already built and installed the port given the short- > circuiting that will then take place, avoiding the updated > Portfile. Flat also copes better with other types of dynamism in > the collection - say gettext depends on libintl for a few years, > then one day somebody realizes that gettext only needs a few > functions from libintl and would be better off implementing those > functions itself, so they do this in the next release of gettext. > The Portfile maintainer for gettext realizes this and removes the > libintl dependency. Boom, all those ports which depended on > gettext with the assumption that they'd get libintl for free now > break. Finally, a flat dep space lends itself well to automation > - if kvv ever implements something similar to DarwinBuild for > MacPorts, that mechanism will find every single port something > depends on and, presumably, update the Portfile accordingly. At > that point, the hierarchy becomes flattened anyway. > > Despite having a lot more verbiage on the subject of flat > dependencies, I don't actually have a firm preference for either - > I can still see both sides of the argument fairly clearly. > > Thoughts? -- Kevin Ballard http://kevin.sb.org kevin(a)sb.org http://www.tildesoft.com

1 0

Unstated dependencies on gettext
by Kevin Ballard 29 Dec '06

29 Dec '06

After having updated gettext, I'm finding a number of ports that are linking against libintl (provided by gettext) but don't declare a dependency on gettext. For example, gsed links against libiconv, but doesn't declare a dependency on gettext. The question I have is, would some of these ports have worked if gettext wasn't installed, but just happen to link against libintl for extra functionality if it's there? I don't want to go adding gettext dependencies all over the place if it's not strictly needed, but on the other hand I'd like to be able to look up all ports that link against gettext, since upgrading it changed the major version number (actually, only version number) of the library and so everything has to re-link. -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

2 3

neon port missing dependencies?
by Kevin Ballard 28 Dec '06

28 Dec '06

libneon links against libintl, which is provided by gettext, but doesn't depend on the gettext port. It also has a couple other issues, but this one just bit me in the ass when I upgraded gettext, which apparently bumped libintl from libintl.3.dylib to libintl.8.dylib, and so broke some other installed ports. I upgraded all the ones that claimed dependency on gettext, but libneon still failed since it didn't claim this. I have a quick-n-dirty change to the Portfile ready which adds gettext, libiconv, and zlib as library dependencies. Shall I go ahead and check it in? -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

3 2

zile update
by Michael Stevens 25 Dec '06

25 Dec '06

Hi. I've submitted a patch to update the zile port to the current release as ticket 11183. Michael (still mentioning things here till trac & so on is more sorted)

1 0