1 |
Alan McKinnon <alan.mckinnon <at> gmail.com> writes: |
2 |
|
3 |
|
4 |
> I doubt dpkg and rpm aren't going to be much use to you, unless you |
5 |
> really want to run two package managers. Besides, both are not |
6 |
> especially useful with the front ends apt* and yum. |
7 |
|
8 |
I'd just use those to unpackage and maybe preprocess some of the codes. |
9 |
|
10 |
Agreed. I do not want a full blown deb or rpm package manager just |
11 |
a way to install and evaluate some of those codes before beginning a more |
12 |
arduous and comprehensive task. Maybe I should just put up a RH/centos box |
13 |
and evaluate codes there. It seems *everything* I want to test and look at |
14 |
in the cluster and hpc world, as a rpm or deb package; so I'm looking for a |
15 |
time saver, to surf thru the myriad of codes I'm getting; many look very |
16 |
cool from the outside, but once I run them, they are pigs....... |
17 |
|
18 |
Then a slick way to keep them secure and clean it out. Maybe I need chroot |
19 |
jails too? I spend way to much time managing codes rather than I do actually |
20 |
writing code. I feel confused often and cannot seem to master this |
21 |
git_thingy.... I have not code seriously in a long time and now it is |
22 |
becoming an obsession, but the old ways are draining my constitutional |
23 |
powers..... |
24 |
|
25 |
|
26 |
> Any special reason why you don't instead download the sources and build |
27 |
> them yourself with PREFIX=/usr/local ? |
28 |
|
29 |
Lots of errant codes flying everywhere so you have to pull a code audit |
30 |
to see what's in the raw tarballs before building. That takes way too much |
31 |
time. I'm working on setting up several more workstations for coding to |
32 |
isolate them from my main system. This approach you suggest is: error prone, |
33 |
takes too much time, and I'm lazy and sometimes even stupid. |
34 |
I need a structure methodology to be a one man extreme_hack_prolific |
35 |
system that prevents me from doing stupid things, whilst I'm distracted. |
36 |
|
37 |
|
38 |
Maybe I should just put up a VM resources on the net, blast tons |
39 |
of tests thru the vendors hardware and let them worry about the |
40 |
security ramifications? Some of it is these codes are based on 'functional |
41 |
languages' and I just do not trust what I do not fully understand. Stuff |
42 |
(files etc) goes everywhere and that makes me cautiously nervous. I have |
43 |
/usr/local for manual work and /usr/local/portage for ovelays (layman) but |
44 |
it's becoming a mess. There where to I put the work effort that is a result |
45 |
from repoman. Those codes seem to be parallel projects often |
46 |
when the code I'm evaluating needs to be cleaned up or extend to properly |
47 |
test. Furthermore I have a growing collection of file that result |
48 |
from kernel profiling via trace-cmd, valgrind, systemtap etc etc. |
49 |
As soon as I delete something, I need to re-generated it for one |
50 |
reason or another...... I just hope that this repo.conf effort |
51 |
helps be get more structurally organized? |
52 |
|
53 |
|
54 |
Did you see/test 'travis-ci' yet? [1] I'm not sure it's the same |
55 |
on github [2] but some of the devs are using it on github. |
56 |
|
57 |
|
58 |
|
59 |
James |
60 |
|
61 |
[1] http://docs.travis-ci.com/ |
62 |
|
63 |
[2] https://github.com/travis-ci/travis-ci |