ibmiperzl vs. ibmichroot: duplication of effort

[Aaron Bartell]

##Preamble I've been thinking of the duplication of effort being done with ibmiperzl and ibmichroot projects, and it hit again today as I was writing an article on how to use node-gyp to compile Node.js modules. Compiling with node-gyp specifically requires python 2.7. Currently the deps in ibmiperzl allow for python 2.6.8 as the most recent version.

In ibmichroot we manually put together dependancies in pkg_perzl_<name>-x.x.x.lst files by first reviewing the deps on perzl.org and then paste the fully qualified URL. I don't really have an issue with this since it is minimal effort and puts us in control of how installs on IBM i work.

The issue is we have two different means of obtaining packages from perzl and inherently two different repos to maintain.

The other issue is that we will be confusing the community. "When do I use each?".

Possible solution...

I am wondering if we should change pkg_setup.sh to support the features/actions of wwwperzl.sh: list, wgetv, wget, rpmv, rpm. And then give ibmiperzl an EOF (end of life).

##Thoughts?

[Former user]

No, two different methods entirely.

More ...

chroot_setup.sh and pkg_setup.sh are planning to be a IBM PTF in LPP OPS (end of Nov maybe). The xxx.lst files are intended to "work" without DIY looking around the perzl planet to figure out what you need next.

wwwperzl.sh is gigantic project with full perzl generated dependency tree downloaded. This is just way too much data for an IBM PTF to handle.

I suggest we simply do 'what we can' to get the new chroot/pkg setup method 'complete tasks as possible' by the end of Nov.

[Aaron Bartell]

I suggest we simply do 'what we can' to get the new chroot/pkg setup method 'complete tasks as possible' by the end of Nov.

Sounds good.

Do you think we should continue to update the ibmiperzl project (i.e. update dependency lists)? Or rather, where do you stand on the ibmiperzl project?

[Former user]

Nothing wrong with periodic updates of 'new stuff' added to wwwperzl.sh. However, it is a significant time effort to 'web download' all the dependency stuff, so i don't do it regularly.

BTW -- Yes, i know we disagree about 'the value' always 'the latest stuff', but, well, hey, IBM i people are still living on out of service V5R4 approaching 15 years (half a career), PASE in these releases is old by perzl standards! i mean, wwwperzl.sh move too fast, and we end up with nothing running on IBM i for the majority of guys.

[Aaron Bartell]

Aka, wwwperzl.sh move too fast, and we end up with nothing running on IBM i for the majority of these guys. Understand?

We could allow support for older aix releases to remain, but any further work we do is for more recent versions of IBM i. I thought that's what the param of aix53 and aix61 were for?

At the end of the day all I am proposing is choice. Right now we force people to select a handful of old releases when we could give them the choice to install any of the versions offered on perzl.org.

Btw, I am not asking you to accomplish this task and instead more getting you on board with the concept so others can fork/pull.

[Former user]

Me? I created wwwpersl.sh (among others), i already participate (toot toot chug chug).

So, what means 'get on board"???

[Aaron Bartell]

So, what means 'get on board"???

Probably a pushback misinterpretation by me. We are good. I am closing this issue.