Mail Archives: geda-user/2015/07/10/10:57:23
On Fri, 10 Jul 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Fri, Jul 10, 2015 at 4:10 AM, Vladimir Zhbanov (vzhbanov AT gmail DOT com)
> [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>> On Thu, Jul 09, 2015 at 07:00:00PM -0400, Dave McGuire (mcguire AT neurotica DOT com) [via geda-user AT delorie DOT com] wrote:
>>> On 07/09/2015 06:35 PM, Svenn Are Bjerkem (svenn DOT bjerkem AT googlemail DOT com)
>>> [via geda-user AT delorie DOT com] wrote:
>>>> What is a good way to test out patches without having to garble up a
>>>> clean install of the released geda? Try it out on a separate computer or
>>>> a virtualbox?
>>>
>>> Oh good heavens no. Just use a different --prefix on your ./configure
>>> command line.
>>
>> This doesn't solve the problem if you want a clean environment.
>> Your config files would be still used.
>
> How much danger are people really in from a testing version of gEDA?
> Are you guys worried about malware hiding in it or something?
When I have this issue, my main concerns are:
- a new version may require changes in config or rc files and that could
ruin old versions
- a new version may overwrite component/footprint library files that may
break existing designs
- a new version may have library dependencies that are incompatible with
an old version
For the first two a different installation path (prefix) is enough. When I
hit the 3rd, I use chroot.
My generic (not limited to geda) approach is that I have a semi-stable
host system which typically lags 0.5 .. 2 years behind latest stuff.
Then I have (or can easily set up) chroot with the
latest-hottest-unstable stuff and I usually have a chroot with a much
older system for cases when I need to revive bitrotten code.
There's a minor hassle with chroot regarding to X, but that's easy to
solve and I usually put it in a shell script that wraps chroot.
Regards,
Igor2
- Raw text -