revision convenience

[RJVB (René Bertin)]

I don't think I'm the only one who has a tendency to forget removing a revision number after upgrading the port version. Recently that happened once too often (and I also wanted a clean way to revbump or not depending on platform) so I wrote a little convenience route:

proc revbump_for_version {r v {p 0}} {
    global version revision subport os.platform
    if {${p} eq 0 || ${os.platform} eq ${p}} {
        if {[vercmp ${version} ${v}] > 0} {
            return -code error "remove revbump (revision ${r}) for ${subport}"
        }
        uplevel set revision ${r}
    }
}

In its most basic form it revbumps if the port version is not newer than the reference version; otherwise it raises an error forcing me to remove the statement.

Extremely simple, maybe a version of this can be merged into the base revision statement at some point.

[raimue (Rainer Müller)]

I don't understand this. How is this supposed to be used in Portfiles?

[RJVB (René Bertin)]

the basic way I use it is something like

name    foo
version  1.2
# revbump because of a patch that will be included in the next upstream release
revbump_for_version 1 1.2

If I forget to remove the revision when upgrading to 1.3 I'll get an immediate error.

Evidently even I rarely forget to remove a revision line if it's right under the version declaration, but that isn't always the case when you work with lots of subports.

[raimue (Rainer Müller)]

Specifying the version number twice in the same file is not convenient at all. You should even see a port lint warning for this.

If we really need to do something about this, I could think of extending the version option syntax to version <version> [<revision>]. However, this would make the Portfile syntax ​non-orthogonal, as there would be multiple ways to specify the revision.

For these kinds of mistakes it would actually be better to have a checker for patches against Portfiles detecting such problems (see checkpatch.pl for ​Linux or ​QEMU). If the patch increases the version, but the revision was not reset to 0, throw an error.

[larryv (Lawrence Velázquez)]

Replying to raimue:

If we really need to do something about this

I don’t think that we do.

[RJVB (René Bertin)]

Replying to raimue:

Specifying the version number twice in the same file is not convenient at all. You should even see a port lint warning for this.

I'm not seeing any warnings, and why would lint warn against comparing ${version} against another variable which happens to be set to the same value? (then again port lint is claiming I include a PortGroup a 2nd time on the subsequent line which in fact includes another PortGroup...)

If we really need to do something about this, I could think of extending the version option syntax to version <version> [<revision>].

I don't see how that would help with in fact the only port where I'm really using this little wrapper. That one bundles the KF5 frameworks as over 60 subports which all share the same version but could all have a different revision. EDIT: the version is set collectively so I couldn't use your proposed syntax.

For these kinds of mistakes it would actually be better to have a checker for patches against Portfiles detecting such problems (see checkpatch.pl for ​Linux or ​QEMU). If the patch increases the version, but the revision was not reset to 0, throw an error.

Wouldn't you get a similar problem with Portfiles that have multiple subports (which can have different versions and/or revisions)?

[raimue (Rainer Müller)]

port lint warns when you hardcode the version number instead of using ${version}. I just noticed it only does this with --nitpick. My proposed idea was to have the information on the same line. No, this would not help in this case. I still had not understood your problem. Such complex Portfiles should also not be the usual case.

Wouldn't you get a similar problem with Portfiles that have multiple subports (which can have different versions and/or revisions)?

Assuming such a script is run in the git repository (or against the original Portfile), it could run this check for all subports.

[RJVB (René Bertin)]

Replying to raimue:

port lint warns when you hardcode the version number instead of using ${version}. I just noticed it only does this with --nitpick.

Indeed, but it rightly puts 'seems to' in the message.

My proposed idea was to have the information on the same line. No, this would not help in this case. I still had not understood your problem. Such complex Portfiles should also not be the usual case.

True, and I'd hope my kind of sloppiness is also not the usual case (though I'm less certain there :)).

Does Tcl allow putting the info on the same line without actual modification of the syntax? Something like

version x.y ; revision N

would read almost the same as your proposition and make it less likely to forget removing a revision.

Assuming such a script is run in the git repository (or against the original Portfile), it could run this check for all subports.

Yes, I assume it could be as complex as needed, but then we'd almost have to consider interfacing it to base somehow, a Tcl script that includes the relevant libraries so it can do actual Portfile parsing. There's an additional detail that wasn't really relevant until now: KDE releases their frameworks, applications and "plasma" stuff in bundles, so it makes sense to declare the current version in the PortGroup. That means you need to parse the whole Portfile in order to know the version number.

I suppose one could add a check to port lint, where it compares the current newest installed version with the version provided by the port, but how often does one lint a port for just a simple version upgrade?

All in all this is beginning to look like killing a gnat with a Stinger missile ;)

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

the basic way I use it is something like

name    foo
version  1.2
# revbump because of a patch that will be included in the next upstream release
revbump_for_version 1 1.2

If I forget to remove the revision when upgrading to 1.3 I'll get an immediate error.

I admit that I have done something similar in the php port, because that is a very complicated port and I sometimes forget. However, I don't think this is too difficult to remember to do for simple ports. I use ​a script to update the version in my ports, and it knows to remove the revision line.

[RJVB (René Bertin)]

Well, we agree it's not too difficult to remember, and forgetting (to do it) isn't the perfect term either. It's more about thinking about it at the right time. Any kind of script helps of course, but to be of real use it would have to be a script for an editor where revision lines are removed interactively (that way it won't remove the wrong ones if there are multiple).