gmane.os.apple.macports.devel

Re: Tracking which ports were installed explicitly

Ryan Schmidt — 2008-12-04T03:30:04

On Dec 3, 2008, at 20:46, Rainer Müller wrote: We also need to consider that changes have probably occurred in registry1.0 since then which may not have been merged into registry2.0.

Re: Port shared-mime-info: remove dependency of perl5?

Rainer Müller — 2008-12-04T03:02:04

set perl5.bin ${prefix}/bin/perl [...] depends_lib path:${perl5.bin}:perl5.8 So as a workaround uninstalling perl5.8 and any p5-* port and then installing perl5 before any p5-* port should satisfy this dependency. If changing dependencies from perl5.8 to perl5 breaks ports, we should delay the changes until 1.7.0 is out. [...] Either revert back to perl5.8 as dependency or make perl5 an "empty" port with 'depends_lib port:perl5.8' only. Rainer

Re: Tracking which ports were installed explicitly

Rainer Müller — 2008-12-04T02:46:29

Using a pseudo-port like 'world' sounds like a very nice and elegant idea to me. But checking for dependents is currently a very expensive operation. To find all dependents the current code iterates over the whole dep_map, which can grow very large depending on the number of ports being installed. If you never heard about dep_map, take a look in your own install: bzless /opt/local/var/macports/receipts/dep_map.bz2 And then you will see why searching and modifying this file is so expensive. Therefore we should focus on finishing registry2.0. This was already started by Chris Pickel (sfiera) in Google Summer of Code 2007. The code was merged to trunk, and it is also already distributed with releases, but it is not used at all yet. registry2.0 plans to use a sqlite db instead of plain text files for dependency tracking (dep_map) and receipts. This should hopefully make such search operations a lot faster and also make the registry more extensible. I tried to get a statement about the status of registry2.0 from Chris some time ago in April, but the only response was that he is busy. So I don't know what is left to complete registry2.0. Rainer

Re: Tracking which ports were installed explicitly

Neil — 2008-12-04T01:44:43

On 3 Dec 2008, at 16:13, Ryan Schmidt wrote: I'm not a huge fan of "Me too." posts to mailing lists, but.... Me too. (I value the non-interactivity.) This sounds like the right way to go about it to me.

Re: Port shared-mime-info: remove dependency of perl5?

Ryan Schmidt — 2008-12-04T01:40:15

Actually p5-xml-parser is a member of the perl5 portgroup, which in MacPorts 1.6.0 depends on perl5.8 but which in MacPorts 1.7.0 will depend on perl5. Yes... Since shared-mime-info does have the line "configure.env-append INTLTOOL_PERL=${prefix}/bin/perl" it appears that it really does want to use perl itself, so it is proper to declare a dependency on perl.... If we release MacPorts 1.7.0 very soon, it's not an issue... We have a beta of 1.7.0 out already. Not sure how long it will take to turn that into release candidates and a final release. Not sure what we should do here.

Port shared-mime-info: remove dependency of perl5?

Rolf Würdemann — 2008-12-03T23:55:44

Re: [43026] trunk/dports/devel/git-core/Portfile

Joshua Root — 2008-12-03T22:30:44

Could be that git-core includes code that uses unixODBC only if the latter is present at build time. If so, the alternative solution would be to make sure it never includes that support. - Josh

Re: [43026] trunk/dports/devel/git-core/Portfile

Simon Ruderich — 2008-12-03T21:58:10

Re: [43024] trunk/dports/x11/xorg-xcb-proto/Portfile

Ryan Schmidt — 2008-12-03T21:37:34

Presumably only one python version can be selected at a time? Right now, nothing prevents a user from selecting both the +python25 and +python30 variants. You should add a variant for python26 as well. You should mark all three variants as conflicting with one another. And you should have the new +python26 variant be the default, unless the user has chosen another one. You should also use configure.python instead of configure.env-append PYTHON=. I didn't remember if that was already in MacPorts 1.6.0 or whether it'll be new to 1.7.0, but the ChangeLog seems to indicate it was in 1.6.0. I don't think I've seen a strsed (or, any other string manipulation command) used as part of a depspec. Does that really work? I removed it in my patch and just wrote out the numbers. It also helps when people want to grep the portfiles to see e.g. what all depends on python26 ("grep :python26 */*/Portfile"). Your python26 was a runtime dependency but your python25 and python30 were library dependencies. I didn't know which is right. I made them all library dependencies in my version. Attached is my patch, though again I haven't tested it.

Re: Tracking which ports were installed explicitly

Joshua Root — 2008-12-03T21:35:42

If it's done as proposed in the ticket, you would do 'port dependents foo' (or rather its internal equivalent) to see whether foo is orphaned. If it has no dependents, it's orphaned. Explicitly installing a port adds 'world' as a dependent. - Josh

Re: Tracking which ports were installed explicitly

Andre Stechert — 2008-12-03T21:27:48

Didn't see anything about counts of the implicit dependencies in the ticket or in this thread. The states of a port are probably "explicitly installed", "implicit against 1 other port", "implicit against 2 other ports", etc., right? Otherwise, you have the potential of setting the orphaned bit too early. Also, the "explicit" bit should probably be independent of the implicit dependency count. On Wed, Dec 3, 2008 at 1:13 PM, Ryan Schmidt public.gmane.org> wrote:

Tracking which ports were installed explicitly

Ryan Schmidt — 2008-12-03T21:13:33

Joshua proposed that we should track which ports were installed explicitly (via "sudo port install x") vs. which ports were installed via dependencies. As he said in the ticket -- http://trac.macports.org/ticket/15260 : Some discussion has taken place in the ticket and I'd like to move that discussion to this mailing list so we can get more input, and since it's easier to discuss things on the mailing list without cluttering up the ticket. Once we reach a consensus on what should be done, a summary can go into the ticket. I mentioned the parallel with CPAN, which to my recollection has a feature where when you uninstall X, and if it depends on Y, and nothing else depends on Y, it will ask interactively if you want to uninstall Y as well. I pointed out that MacPorts has no interactivity at this time (except if you explicitly enter interactive mode by typing just "port"), and that I value this guarantee of non- interactivity. Rainer and I liked the idea of a new pseudo-port (I called it "unused"; Rainer called it "orphaned" which is probably better) that you could use to deal with the ports that had been installed as dependencies of things which themselves have already been uninstalled. Then you could do the usual things like "port installed orphaned" or "sudo port uninstall orphaned". The idea is to have MacPorts keep track of what you installed explicitly and what was installed automatically as a dependency. I think it might be of value to be able to manipulate this after the fact, both by changing something from an explicitly installed port to an automatically installed dependency (e.g. things that you would have let MacPorts install as a dependency except that you had to install it explicitly to get a particular variant) and by changing something from an automatically installed dependency to an explicitly installed port (e.g. things that you let MacPorts install as a dependency but which you want to keep around). Though I'm not convinced it's essential, and maybe it can be deferred until later anyway. I also brought up the need to consider how this feature would affect the MacPorts framework/API. Probably a new pseudo-port wouldn't need any special changes in the API which would be good. I'd like to solicit opinions on any and all of these matters, so let the discussion begin!

Re: [43026] trunk/dports/devel/git-core/Portfile

Adam Mercer — 2008-12-03T21:08:43

Why is this needed, I've been using git-svn for quite a while and don't have the unixODBC port installed and I've never ran into problems? Cheers Adam

Re: [43004] trunk/dports/graphics/netpbm

Marcus Calhoun-Lopez — 2008-12-03T08:17:38

Thank you for pointing this out. It was fixed in r43012.

Re: [43004] trunk/dports/graphics/netpbm

Ryan Schmidt — 2008-12-03T08:08:01

On Dec 3, 2008, at 01:05, mcalhoun-/EBbbHb69GVg9hUCZPvPmw< at >public.gmane.org wrote: Shouldn't the closing bracket be after the asterisk instead? eval move ${destroot}${prefix}/bin/doc.url [glob ${destroot}$ {prefix}/misc/*] ${destroot}${prefix}/share/netpbm

Re: [42996] trunk/dports/x11/xinit

Jeremy Huddleston — 2008-12-03T07:41:30

Thanks Ryan =) On Dec 2, 2008, at 21:10, Ryan Schmidt wrote:

Re: [42996] trunk/dports/x11/xinit

Ryan Schmidt — 2008-12-03T05:10:38

[snip] FYI it's preferable to use built-in tcl commands rather than starting a new shell using "system" where possible. So here's how that would look: post-destroot { move ${destroot}/Library/LaunchAgents/org.x.startx.plist ${destroot}/ Library/LaunchAgents/org.macports.startx.plist move ${destroot}/Library/LaunchDaemons/org.x.privileged_startx.plist ${destroot}/Library/LaunchDaemons/org.macports.privileged_startx.plist xinstall -d ${destroot}${prefix}/lib/X11/xinit/xinitrc.d eval xinstall -m 755 [glob ${filespath}/xinitrc.d/*.sh] ${destroot}$ {prefix}/lib/X11/xinit/xinitrc.d } I think this is right, but I've just typed it in here and haven't tested it. Also note you shouldn't put a slash before ${prefix}; $ {prefix} begins with a slash already.

Re: 1.7.0 beta 1 tagged and ready to test

Bryan Blackburn — 2008-12-03T02:51:39

On Sun, Nov 30, 2008 at 11:15:28AM +0100, Anders F Björklund said: I was pondering just dumping it into /users/blb or similar, to denote the non-release status... The DESTDIR support should now work as of r42978 (trunk) and r42979 (branch release_1_7). The root priv bit can be worked around with the --with-install-(user|group) switches to configure, but I don't know what kind of an effect that may have on the final install from DMG. Bryan

Re: [42968] trunk/dports/audio/twolame

Bryan Blackburn — 2008-12-03T02:42:27

On Tue, Dec 02, 2008 at 07:25:15PM -0600, Ryan Schmidt said: Perhaps, how is cyrus failing? If it's an issue of older headers being incompatible with the new version, then you need to make sure the local -I stuff (-I./include, -I../includes, whatever it may use) appears before -I${prefix}/include in Makefiles. If it's with libraries, I believe a similar tactic with -L will work. Otherwise, it depends. Bryan

Re: [42862] trunk/dports/lang/gst/Portfile

Ryan Schmidt — 2008-12-03T02:12:27

On Dec 1, 2008, at 16:16, Bryan Blackburn wrote: I noticed that too, and also this: The variant to disable X11 support should be called no_x11, not nox. The nox variant is marked as conflicting with tk but there is no valiant called tk. Did you mean tcltk? You shouldn't use the conflicts word twice in a single variant declaration; just list all the conflicting variants after the word "conflicts". gtk and tcltk should only be made the defaults if the user has not already chosen to disable X11. Attached is my initial pass at fixing this. However there remain these questions: What is the relationship between these variants? Is there ever a case when one would want to disable the gtk or tcltk variants? If so, it will be difficult for a user to do so, due to a long-standing MacPorts base bug which makes it so that if you install a port with negative variants (sudo port install gst -gtk -tcltk) and then upgrade it (sudo port upgrade gst), the deselected variants will be added again. Perhaps the variants should be changed to no_gtk and no_tcltk. Is there ever a case when a user would want to select neither gtk nor tcltk nor no_x11? Also, the variants need descriptions.

Re: [42968] trunk/dports/audio/twolame

Ryan Schmidt — 2008-12-03T01:25:15

On Dec 2, 2008, at 18:37, blb-/EBbbHb69GVg9hUCZPvPmw< at >public.gmane.org wrote: Neat! Can we fix cyrus-sasl2 in the same way?