[developer] kdelibs4 4.14/git/master portfile and directory

[RJVB (René Bertin)]

As announced on the kde-mac ML, I have prepared a Portfile and directory to install the git/master (4.14) kdelibs4 branch.

This port installs fine with the remaining KDE ports left at their current versions (KDE 4.12.5). However, I see this mostly as a convenience port for developers working on KDE/MacPorts and interested to work directly on a branch that is still open for bug reports and fixes.

[RJVB (René Bertin)]

zip archive containing port dir kdelibs4/files

[RJVB (René Bertin)]

Cc Me!

[RJVB (René Bertin)]

The Portfile expects a locally cloned working copy of ​git://anongit.kde.org/kdelibs in ${prefix}/src/KDE/kdelibs/kdelibs-git

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

The Portfile expects a locally cloned working copy of ​git://anongit.kde.org/kdelibs in ${prefix}/src/KDE/kdelibs/kdelibs-git

This is an extremely odd requirement for a port in our public ports tree. I don’t particularly like it.

[larryv (Lawrence Velázquez)]

Why the +no_root variant? Why not just check ${install.user} and change the port’s behavior as appropriate?

Plus, we don’t do “no_FOO” variants anymore.

[larryv (Lawrence Velázquez)]

Other comments:

• It’s not acceptable for revision to be a date. The point of revision is to represent the versioning of the Portfile, not of the packaged software. If you want to incorporate the date into the version, you’d do something like

  version 4.14.0-20140902
  

• master_sites is not used if fetch.type is “git”.
• You use this idiom frequently:

  variant FOO {}
  if {[variant_isset FOO]} { do some stuff }
  

  Why not just put the stuff inside the variant script? That’s our convention, and it’s a lot cleaner.
• There’s no reason to check whether startupitem.install is available. The released version of MacPorts has it, so all Portfiles should just assume it’s there.

[danielluke (Daniel J. Luke)]

Replying to larryv@…:

Other comments:

• It’s not acceptable for revision to be a date. The point of revision is to represent the versioning of the Portfile, not of the packaged software. If you want to incorporate the date into the version, you’d do something like

Is this policy? I don't think it's necessarily a bad idea to use/abuse revision like this.

[ryandesign (Ryan Carsten Schmidt)]

revision is an unsigned integer. It should start at 0 and increase by 1 for each time the port should be rebuilt but its version does not change.

[ryandesign (Ryan Carsten Schmidt)]

This is a portfile for kdelibs4, but of course we already have a kdelibs4 port. So... what are you thinking we should do with this new portfile?

[RJVB (René Bertin)]

First off, and I'm sorry if that wasn't clear, this is NOT a submission for a new port, or for an upgrade of an existing port to be included in an upcoming release. I've uploaded it hoping to help others working on KDE on OS X, allowing them to grab the port directory from here, install it in their local port registry and then use it. That's why I labelled it as an enhancements instead of a If there's a more appropriate place to put this kind of thing online I'm happy to use that, but in the meantime I thought there's little harm putting it here.

This "special status" is why I took the liberty to deviate from conventions/dogma.

• I kept a number of settings that aren't used for git Portfiles; outcommented others : I didn't want to change the portfile too much, allowing for easy-enough reverting to a stable release version.
• The revision number is indeed the date of the commit expected in the local git clone. The result is that the copy of the clone that MacPorts makes has an invariant name. I find that makes for an easier workflow if you're making modifications in the local git clone and then copy them into MacPort's copy before rebuilding.
• That local git clone. Remember that this is a port aimed at other developers. Indeed I could have put a reference to the remote repo there, but one way or another those other developers are probably going to want change it for a reference to their own local git clone ... so I put in a reference to a reasonable location.
• no_root variant: not mine. It must have been in the original kdelibs4 portfile. I did add a +nostrip variant, which I *could* have made the default given this is a developers portfile...
• startupitem.install: idem, not mine.
• variant definition syntax: again, it's the syntax I copied from the portfiles I work(ed) off. I agree it's not a very clean syntax, but wasn't even aware there's a cleaner way to do things. (Or, IIRC, I tried at some point and the variant wasn't picked up so I went back to the current redundant way.)

So to answer Ryan's question: I'm not particularly expecting you (plural) to decide anything. I think trac is a place with resources for MacPorts developers, and this is just that. BTW, I presume attachments can be added/replaced by others too, or is that something only the submitter can do (just like permissions for changing things like keywords are reserved to ... admins)?

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

First off, and I'm sorry if that wasn't clear, this is NOT a submission for a new port, or for an upgrade of an existing port to be included in an upcoming release. I've uploaded it hoping to help others working on KDE on OS X, allowing them to grab the port directory from here, install it in their local port registry and then use it. That's why I labelled it as an enhancements instead of a If there's a more appropriate place to put this kind of thing online I'm happy to use that, but in the meantime I thought there's little harm putting it here.

Ah. Perhaps a wiki page linked from KDE might work better? It would also be editable :)

• The revision number is indeed the date of the commit expected in the local git clone. The result is that the copy of the clone that MacPorts makes has an invariant name. I find that makes for an easier workflow if you're making modifications in the local git clone and then copy them into MacPort's copy before rebuilding.

The problem there (and this is why we don’t abuse revision like this) is that we want to divorce upstream versions from Portfile versions, so to speak. If you use revision as part of your upstream version, there’s no way to distinguish whether a revbump is due to a Portfile adjustment or an upstream change, short of looking at the Subversion log. So any version information that pertains to the software being packaged should be entirely contained in version.

• That local git clone. Remember that this is a port aimed at other developers. Indeed I could have put a reference to the remote repo there, but one way or another those other developers are probably going to want change it for a reference to their own local git clone ... so I put in a reference to a reasonable location.

Another benefit of a wiki page would be that you could clearly spell out these special requirements and procedures. Perhaps even provide step-by-step instructions for getting set up. Or anything you’d like!

[mkae (Marko Käning)]

Replying to larryv@…:

Another benefit of a wiki page

Hi Larry,

actually we do have a wiki page especially dedicated for KDE development and I try my best to keep it as up-to-date as possible.

As nicos is releasing KDE 4.13.3 ports ATM we'll soon have stuff for 4.14 listed there. As you'll see there we've got quite a bit of various kinds of instructions there.

Greets, Marko

[mkae (Marko Käning)]

Cc Me!

[RJVB (René Bertin)]

full patchset of all my current changes to kdelibs 4.14 git/kde4.14.2 (including the Keychain mods), on the brink of tagging for 4.14.3