New feature for Portmaster (ultra-speed improvement)

M

Mustela

Hello. I am thinking about a new feature for portmaster: the option "--ignore-revs[=n]" to ignore updates if iy has only found a port revision.

For example, if I have Thunderbird 24.6.0_2, why is it necessary for me to update to 24.6.0_3? With this option, I can reduce notably (veeeery notably) the update times of the system (ok, with caution). But this feature is going further, because I can select (with the optional n) the number of revisions for ignore. Then, for example, using --ignore-revs=2, I will not update the Thunderbird 24.6.0_1 if the new revision is _2 or _3, but yes if it's _4.

What do you think? Is it good idea? Yes, it can be dangerous for upgrading the full system, but I, sometimes, update some packages with only version changes (no port revisions) and really few times (or never) I havee problems. Other thing is the "comma" number of revision, that I don't know what they are exactly. It can be contemplated with, for example, --ignore-revs[=n1[,n2]], when:
  • if no options are passed, never update any port with only port revision changed and not software version updated
  • if n1 passed, number of n1 revisions has processed for update
  • if n2 passed, number of n2 "revisions of revision?" has processed for update
Thinking more, this option can be saved as a system variable (or configuration file), for not remembering always and writing for package updates.

Please, tell me something...

Regards.
 
How are you going to know which new revisions are minor enough to be skipped? The revision numbers are upped when there is a good reason to do so. What you would be doing is making your own guesses if they are significant enough to warrant a recompilation of the port. Are you that good of a expert that you can always guess right? I don't think so.

To make it really clear. I do consider myself a capable programmer and I do know a thing or two about the FreeBSD ports system. Yet I wouldn't be able to implement the system you're proposing and the reason is simply that the revision numbers themselves contain no information about why they got bumped up. A number is just a number and the decision if the change is insignificant enough not to warrant a recompilation can not be done without looking at what really got changed in the commit that caused the revision number bump.
 
This is only to improve speed when rebuilding a system for only software changes. Of course, I know that these revisions are for good! But "probably" isn't necessary for some people. This is a simple option that you can utilize or not, like others.

And I'm not an expert, and not a programmer. :(
 
Mustela said:
This is only for improve speed for rebuild system for only software changes. Of course, I know that this revisions is for good! But "probably" isn't necessary for some people. This is a simple option that you can utilize or not, like others.

And I'm not expert, and not programmer. :(
Click to expand...

I understand what you're aiming at. Unfortunately all changes in the revision numbers are done with the intention of forcing a recompilation of the port. Most often the change is in the default options or in the dependencies of the port. The change in the revision number is to make sure those changes get caught up in the compiled packages.

A good example of such a change is the devel/libevent2 change from today. One of the ports that depend on it is sysutils/tmux (that I happen to use). The sysutils/tmux got changed to depend only on devel/libevent2 instead of offering an option to choose between devel/libevent and devel/libevent2. To make sure all the users of sysutils/tmux port get this change the sysutils/tmux port got its version number upped from 1.9.a_1 to 1.9.a_2. There's no way anyone could know by just looking at those two numbers if the change is such that it could be skipped. In this example the change is sort of optional but there are other types of changes (read: security updates) that are done to fix a completely broken port that is doing something dangerous it its present version and recompiling that port to the updated version is not optional at all.
 
kpa said:
How are you going to know which new revisions are minor enough to be skipped? The revision numbers are upped when there is a good reason to do so. What you would be doing is making your own guesses if they are significant enough to warrant a recompilation of the port. Are you that good of a expert that you can always guess right? I don't think so.

To make it really clear. I do consider myself a capable programmer and I do know a thing or two about the FreeBSD ports system. Yet I wouldn't be able to implement the system you're proposing and the reason is simply that the revision numbers themselves contain no information about why they got bumped up. A number is just a number and the decision if the change is insignificant enough not to warrant a recompilation can not be done without looking at what really got changed in the commit that caused the revision number bump.
Click to expand...

Ok, high and clear (the last is new :))

But this feature can't be literally for all ports. You can use it for packages more than 10MB, or only for non-autobuilds (my Thunderbird is installed by me and not by another package), etc.

It is a little improvement that can semi-update a system with only major changes, no minors. And, if this update has problems, it can remove this feature from the command-line, to update all revisions too and continue.

Moreover, the feature can be accompanied by other, for example, --no-ignore-rev-depends, if I update the system and Thunderbird is only from _2 to _3, it doesn't update, but if gtk2 (Thunderbird depends on it) is 2.24.22_2 and new is _3, rebuild it!

I don't think that's bad...
 
Libevent-2 and libevent2: this is an un-featured parameter of portmaster, that it can't uninstall previous package if a number is newer just before the "-". I will remove manually and then install newer. Probably, it can be changed to support checking the alphanumeric port name and the previous installed version (but I'm repeating, I'm not developer).

Other unfeatured thing is, for example, if I will update libevents, for any reason, portmaster don't check the libraries for the packages that depends on it. Then, I need to rebuild manually too. This isn't more important that the port revision?
 
You must log in or register to reply here.
Back
Top