On 12/17/15 08:33 AM, cpforum wrote:
pkg update -nv give the list of updated package. The problem is that most of
them are just recompiled without changing code.
For example the following package is just recompiled
system/network
0.5.11-2015.0.2.15412 -> 0.5.11-2015.0.2.15420
The last number 15412 goes to 15420 => the package is just recompiled (and they
are every day).
If 0.2 changed to 0.3 I think the code changed.
The purpose of the script is to compare version without suffix.
If the version number without suffix differs the script display the package
(same package is not displayed).
So you know exactly what packages have changed since last pkg update.
Well, if they are recompiled there must be a reason why they are recompiled,
also OI hipster pulls newest vanilla illumos on every update so they at
illumos must have changed something.
To know what actually changed or not I bet it is not enough to look
package suffixes partially,
but one actually nedds to look at the changes at the code itself. If
suffix subversion is changed,
that is the indication that something has changed or recompilation was
needed for some other change.
Anyway it is important to know what changed and what recompiled, too,
but distinguishing those 2 I think needs comparing of the sources not
just name suffixes (at least something triggered it's rebuild and that
is the change etc)
Script also depends as I understand on the numbering scheme and as I
know there are 2 of them, suppose you figure it out in your nice script
but had to mention it:
0.5.11-2015.0.2.15420 and
2.32.1-2015.0.1.0
First one is how Opensolaris and Openindiana in /dev used to do it,
and second one is how OI hipster started doing it.
I like first one much more if it includes version number after release
number, beacause that way one can get application version number back
while staying within release and manage package version updates within
release (like having possible /release and /updates separated)
This problem is partially soften by introducing 'userland-incorporation'
that supposedly allow downgrading packages but naming scheme in OI
hipster is disturbing to me because there was more then one ocasion in
OI hipster life, when it was hard if not impossible to get version of
package back and package back to previous working one. Packages stayed
with newer version of package even if it included new bugs and
incompatibilities.
If wanting to find differences in source code itself, additional problem
is that OI hipster does not publicly host it's source code on
Openindiana servers, after releasing packages changes,but relies on
github's 'upstream download plus patch'.
And that is the problem for any type of release where source
availability should not depend on external hosts to fulfill licenses.
Also, hipster-encumbered needs to have its' source code also separated,
to be able to mirror OI source in US without hipster-encumbered, due to
illogical US patent laws not present elsewhere, that target source code
itself and want to destroy developer's freedom of everyone writing it's
own algorithms.
_______________________________________________
openindiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
