The description in the initial comment is a little off, as
functions are always used. The issue is that some older OS
component packages use an in-line root function rather than
a root.ves model. For example, compare these two models:
Two years ago we changed the pkg2vesta to generate a
root.ves model rather than an in-line function, specifically
in this version:
/vesta/vestasys.org/vesta/extras/pkg2vesta/3
We did this for two reasons:
1. A model is a small value regardless of how much stuff may
be in the directory it comes from. It carries with it a
reference back to the immutable directory in the repository
which allows it to get files and directories in the same
directory. In contrast, an in-line function which captures
values from its definition context can creates a much larger
value. Closures must carry with them everything they
capture from their definition context. In the case of these
in-line root functions, the values are proportional to
entire directory structure of the partial root filesystem
they provide.
2. Fine-grained secondary dependencies get recorded against
individual sub-values of values captured from the definition
context of a function. For example, if
./components/binutils/root is the root_func function from
binutils/2.11.93.0.2-11/build.ves mentioned above (as it
typically would be in a std_env using that OS component), a
dependency recorded against /usr/bin/ld in a filesystem
generated with that function will be recorded as
./components/binutils/root/root/usr/bin/ld. Obviously in
some cases there can be many such dependencies. However,
there aren't very helpful as usually individual files in
such a partial filesystem aren't changed one at a time.
Instead an entire new version of the OS component is
imported. These fine-grained dependencies aren't really
worth their cost. Using a model cuts off these dependencies
and instead there's simply one dependency on the model
(./components/binutils/root).
After we changed pkg2vesta we never went back and changed
all the packages which were generated with the old method.
I believe this is the definitive list of such versions which
need this update:
It's worth noting that these all seem to also pre-date the
changes in pkg2vesta/2 which created a branch for each OS
component version. Instead, each of the above are versions
(and thus immutable directories). We'll need to create a
branch for each with a separate name.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=304837
The description in the initial comment is a little off, as
functions are always used. The issue is that some older OS
component packages use an in-line root function rather than
a root.ves model. For example, compare these two models:
/vesta/vestasys.org/platforms/linux/redhat/i386/components/binutils/2.11.93.0.2-11/build.ves
/vesta/vestasys.org/platforms/linux/debian/i386/components/binutils/2.15-6/1/build.ves
Two years ago we changed the pkg2vesta to generate a
root.ves model rather than an in-line function, specifically
in this version:
/vesta/vestasys.org/vesta/extras/pkg2vesta/3
We did this for two reasons:
1. A model is a small value regardless of how much stuff may
be in the directory it comes from. It carries with it a
reference back to the immutable directory in the repository
which allows it to get files and directories in the same
directory. In contrast, an in-line function which captures
values from its definition context can creates a much larger
value. Closures must carry with them everything they
capture from their definition context. In the case of these
in-line root functions, the values are proportional to
entire directory structure of the partial root filesystem
they provide.
2. Fine-grained secondary dependencies get recorded against
individual sub-values of values captured from the definition
context of a function. For example, if
./components/binutils/root is the root_func function from
binutils/2.11.93.0.2-11/build.ves mentioned above (as it
typically would be in a std_env using that OS component), a
dependency recorded against /usr/bin/ld in a filesystem
generated with that function will be recorded as
./components/binutils/root/root/usr/bin/ld. Obviously in
some cases there can be many such dependencies. However,
there aren't very helpful as usually individual files in
such a partial filesystem aren't changed one at a time.
Instead an entire new version of the OS component is
imported. These fine-grained dependencies aren't really
worth their cost. Using a model cuts off these dependencies
and instead there's simply one dependency on the model
(./components/binutils/root).
After we changed pkg2vesta we never went back and changed
all the packages which were generated with the old method.
I believe this is the definitive list of such versions which
need this update:
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/binutils/2.12.90.0.1-4
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/byacc/1.9-13.1
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/cpp-2.95/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/cpp/2:2.95.4-14
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/flex/2.5.4a-24
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/g++-2.95/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/g++/2:2.95.4-14
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/gcc-2.95/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/gcc/2:2.95.4-14
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/libc6-dev/2.2.5-6
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/libc6/2.2.5-6
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/libstdc++2.10-dev/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/powerpc/components/libstdc++2.10-glibc2.2/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/sparc/components/binutils/2.12.90.0.1-4
/vesta/vestasys.org/platforms/linux/debian/sparc/components/byacc/1.9-13.1
/vesta/vestasys.org/platforms/linux/debian/sparc/components/cpp-2.95/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/sparc/components/cpp/2:2.95.4-14
/vesta/vestasys.org/platforms/linux/debian/sparc/components/flex/2.5.4a-24
/vesta/vestasys.org/platforms/linux/debian/sparc/components/g++-2.95/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/sparc/components/g++/2:2.95.4-14
/vesta/vestasys.org/platforms/linux/debian/sparc/components/gcc-2.95/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/sparc/components/gcc/2:2.95.4-14
/vesta/vestasys.org/platforms/linux/debian/sparc/components/libc6-dev/2.2.5-11.5
/vesta/vestasys.org/platforms/linux/debian/sparc/components/libc6/2.2.5-11.5
/vesta/vestasys.org/platforms/linux/debian/sparc/components/libstdc++2.10-dev/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/debian/sparc/components/libstdc++2.10-glibc2.2/1:2.95.4-7
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/binutils/2.10.91.0.2-3
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/byacc/1.9-18
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/cpp/2.96-87
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/flex/2.5.4a-14
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/gcc-c++/2.96-87
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/gcc/2.96-87
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/glibc/2.2.3-11
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/kernel-headers/2.4.3-12
/vesta/vestasys.org/platforms/linux/redhat/alpha/components/libstdc++/2.96-87
/vesta/vestasys.org/platforms/linux/redhat/i386/components/binutils/2.11.93.0.2-11
/vesta/vestasys.org/platforms/linux/redhat/i386/components/byacc/1.9-19
/vesta/vestasys.org/platforms/linux/redhat/i386/components/cpp/2.96-112
/vesta/vestasys.org/platforms/linux/redhat/i386/components/flex/2.5.4a-23
/vesta/vestasys.org/platforms/linux/redhat/i386/components/gcc-c++/2.96-112
/vesta/vestasys.org/platforms/linux/redhat/i386/components/gcc/2.96-112
/vesta/vestasys.org/platforms/linux/redhat/i386/components/glibc-kernheaders/2.4-7.16
/vesta/vestasys.org/platforms/linux/redhat/i386/components/glibc/2.2.5-39
/vesta/vestasys.org/platforms/linux/redhat/i386/components/libstdc++/2.96-112
/vesta/vestasys.org/platforms/linux/redhat/i686/components/glibc/2.2.5-39
It's worth noting that these all seem to also pre-date the
changes in pkg2vesta/2 which created a branch for each OS
component version. Instead, each of the above are versions
(and thus immutable directories). We'll need to create a
branch for each with a separate name.