NEW PORT: Squirrelmail

[joe@…]

A webmail system which accesses mail over IMAP, included in OS X Server

[joe@…]

Squirrelmail 1.4.5 Portfile

[jberry@…]

I'm not going to commit this, since it isn't my area, but I thought I'd comment on a couple of things:

• Default variants can cause trouble, because they're hard to turn off, and negative variants don't get

remembered across upgrade, which makes default variants hard to use. So I'd look for a way to avoid the default variants.

• Athough this port is written in php, and clearly also needs something like apache in order to be run,

it's not clear to me that there's justification to add dependencies onto that software. Doing so just adds to the proliferation of variants, the issue with default variants, etc. Could the user choose a variant simply by choosing which one to install?

I haven't looked at many php ports, so maybe this is all standard practice. I just thought I'd throw out a few cents... ;) Take them for what they're worth.

[joe@…]

(In reply to comment #2)

I'm not going to commit this, since it isn't my area, but I thought I'd comment on a couple of things:

• Default variants can cause trouble, because they're hard to turn off, and negative variants don't get

remembered across upgrade, which makes default variants hard to use. So I'd look for a way to avoid the default variants.

• Athough this port is written in php, and clearly also needs something like apache in order to be

run,

it's not clear to me that there's justification to add dependencies onto that software. Doing so just

adds

to the proliferation of variants, the issue with default variants, etc. Could the user choose a variant simply by choosing which one to install?

I haven't looked at many php ports, so maybe this is all standard practice. I just thought I'd throw out

a

few cents... ;) Take them for what they're worth.

Hmmm... all of my ports to date have used default variants, and this Portfile is basically modeled after all of my other (approved) ports to date.

Are you saying that when somebody upgrades, the non-default variants that they chose are forgotten?

Perhaps this is best discussed on the list? This sounds like a broader discussion that would potentially affect other ports including mine. I don't mean to sound dismissive, I'm more than happy to make these changes, I just think that perhaps some of the senior DP contributors should weigh in on this. What do you think?

[jberry@…]

(In reply to comment #3)

Are you saying that when somebody upgrades, the non-default variants that they chose are

forgotten?

Default variants are fine--as long as you never need to turn them off. Turning off a default variant requires a negative variant, and negative variants are not stored. So when you go to upgrade, the variant comes back, like the proverbial cat.

So if you would never need to turn off a variant, then a default variant is fine. But that then begs the question of why it's a variant in the first place.

One way to step around this problem is to make sure that there's a postive way of expressing yourself. So by enabling the php5 variant, for instance, you automatically disable the dependency provided by the default php4 variant. So then you don't have to specify a negative variant, just a positive one.

Perhaps this is best discussed on the list? This sounds like a broader discussion that would

potentially

affect other ports including mine. I don't mean to sound dismissive, I'm more than happy to make

these

changes, I just think that perhaps some of the senior DP contributors should weigh in on this. What

do

you think?

I'd love to see a discussion on this topic. That's why I raised the issue. Frankly, I don't know what the right answer is, except that we have a much more robust dependency solution, which I probably won't embark on any time soon.

[yeled@…]

(In reply to comment #3)

I don't mean to sound dismissive, I'm more than happy to make these changes, I just think that perhaps some of the senior DP contributors should weigh in on this. What do you think?

well jberry is probably the man most likely to write the code that parses your Portfile right now. Just thought I'd make you aware :)

Most people would be watching this bug anyway as it's not assigned to anyone yet.

[joe@…]

(In reply to comment #5)

(In reply to comment #3)

I don't mean to sound dismissive, I'm more than happy to make these changes, I just think that perhaps some of the senior DP contributors should weigh in on this. What

do

you think?

well jberry is probably the man most likely to write the code that parses your Portfile right now. Just thought I'd make you aware :)

Most people would be watching this bug anyway as it's not assigned to anyone yet.

Oh... well in that case,

What do you guys propose to replace this? I'm game to whatever you guys collectively think would be better than this. I'm not attached to this technique.

I think a flaw with the current approach is that variants and default variants cannot easily be triggered with dependencies, and even if they could, figuring out what variants to trigger may require a lot of conditional statements. I've already written a message to the list about this, so I'm sorry to sound repetitive!

[mww@…]

its simply that the current dependency mechanism isn't as powerfull as e. g. the one from rpm; this is really the question about a workaround - and I'm unsure myself which road to take (thats why I submitted Joe's other php-ports with this phletora of variants). We currently just can't solve the issue the php-ports do have - alternative dependencies at run-time. Though if in question, I'm always for the less-variants version..

Perhaps I should spend some more time on xpkg to get this problem solved at it's roots.

[mww@…]

I for now have submitted it but stripped all variants and dependencies from it: -if we go the whole way we could also require a mailserver (smtp and imap) -imho these are all runtime dependencies -you really should now what you do with the software - dp can't take do that for you; if you don't know you need some webserver with php for squirrel, its probably not for you

I'm still unhappy with either solutions - but as said, we won't solve the fundamental problem here soon.

btw.: put it into the www category and added 'php' and 'mail'