Am 04.09.2014 um 02:52 schrieb Sylvain Joyeux:
>> I don't see why you can't mix devel with release code.
>> You just set the override for the branch to whatever
>> you want, done.
The idea is now a bit different, we (as discussed internally) want
the release to be as reporoducable as possible. Meaning, if I check
it out 4 years later it should behave as on day one. Including all the
bugs it had. Also release are only supported on the Distros, they
explicitly support.
> This fails if:
> - you want to try a package that did not exist at release time
Package should be then on a 'additional packages' package set. If you
want non release packages, you import an extra package set.
> - the master branch needs an osdeps that was not declared at release time
> - the master branch depends on a package that did not exist at release time
Agreed, these use cases are rather rough as you need to create a custom
package
set / add it to your project package set.
> - the way the package got built changed between the release and now
This is something we do not want. If the package was build before without
option X, we want it to stay this way. As enabling option X might change
the behavior of the package.
> - the repository URL changed between the release and now
The version we are interested in, for the release, should hopefully
still be at
the 'old' url. Actually there were thoughts to mirror external repositories,
to be sure that we can rebuild anything years later.
> - there are differences in the way the package is patched
Same as above. Might change runtime behavior.
> - probably other that I don't remember
>
> I've not implemented support for all these in the flavor system just
> for fun ... They were all concrete problems that people encountered
> (the most problematic one being gui/vizkit that changed from
> cmake_package to ruby_package).
I remember this. The problem we wanted to solve back then was
to make it easy to mix the branches, and have only one set of
osdeps and package definitons. As said above, this does not
match the use case of the release, as the target is reproducibility.
All the osdeps need to be frozen to a specific commit / version,
which is the opposite of how we wanted it in the master/next/stable
system.
Greetings
Janosch
--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik
Universität Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Straße 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Besuchsadresse der Nebengeschäftstelle:
Robert-Hooke-Straße 5
28359 Bremen, Germany
Tel.: +49 421 178 45-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: jmachowin...@informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev@dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
