Please login or register. June 27, 2017, 08:49:51 PM

Author Topic: iconv and simlink  (Read 661 times)

0 Members and 1 Guest are viewing this topic.

owlmind

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
iconv and simlink
« on: December 22, 2016, 07:23:29 AM »
I noticed, that aixtools libiconv replaces aix version of it. Is it a really good solution?
Won't it cause any troubles with AIX TL ans SP updates?
I like that most of your packages doesn't tamper with any system files. And this rplacement doesn't look goog to me.

owlmind

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
Re: iconv and simlink
« Reply #1 on: December 22, 2016, 08:52:28 AM »
Ok great. I checked it. If i instal aixtools iconv, then i update AIX SP iconv is beeing changed by new one. The if i remove aixtools iconv, script change lib to old version, but package system thinks we have new.
I really don't like this.

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1039
  • Karma: +0/-0
Re: iconv and simlink
« Reply #2 on: December 22, 2016, 09:22:13 PM »
Yes, this is a difficult process - as the IBM packaging does not regard others.

I set mine up so that it can install and copy the IBM iconv that is installed at that moment. The uninstall, as you state, returns the previous situation (that is what I could save).

Your case motivates me to adopt some additional logic:

mainly - verify that aixtools member is still in the archive (if you update with AIX SP it will be overwritten), so then uninstall will not do anything.

for years I did not install in /usr/lib ever, but when in /opt/lib it was often missed - /usr/lib/libiconv.a was found and libiconv.so.8 was not there so applications did not load. The loader does not check a new lib directory for a second library with the same .a name.

In this case - and I shall update the wiki directly - you can either uninstall aixtools.gnu.iconv first, or use the -F option to force reinstall the package. It should then save the current libiconv.a as libiconv.a.AIX and add merge the two archives (/usr/lib/libiconv.a.AIX and "aixtools" /usr/lib/libiconv.a)

Thank you for the feedback!

p.s. - for now - if you have aixtools version installed (force if needed) the IBM SP update. This will overwrite the aixtools version. Then force reinstall the aixtools version to reinstall the merger of the files.

I shall work on a new packaging asap.

Michael

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1039
  • Karma: +0/-0
Re: iconv and simlink
« Reply #3 on: December 22, 2016, 10:16:21 PM »
repackaged libiconv - and now rather than a symbolic link the archive is copied.

uninstall of aixtools.gnu.libiconv will only restore saved version when /opt/lib/libiconv.a and /usr/lib/libiconv.a are exact copies.

owlmind

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
Re: iconv and simlink
« Reply #4 on: December 23, 2016, 02:56:02 AM »
I believe that different packages shouldn't change files of each other. It completely compromise the whole idea of packaging system. I have 3 more aix-administrators besides me, one day some of us might forget something during update of one of our hundreds lpars. lpp packages of aix is built so i always can be sure about exact version of each system file  just looking at oslevel version, if foreign package breaks it - i don't see how it's better than rpm packages. Can't use it as it is now. Either it is link or replaced file - it's bad. It turns enterprise unix with elaborated versioning system  into slackware linux.
 

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1039
  • Karma: +0/-0
Re: iconv and simlink
« Reply #5 on: December 23, 2016, 01:03:04 PM »
Yes. I agree actually. One of the main reasons I use mkinstallp, rather than rpm is because rpm packaging has ALWAYS done the kind of update I am doing now, or worse, just overwritten it.

Again, I agree - which is why I try and force the things I package to go to /opt/lib for libraries. As far as iconv goes, I used to not install GNU iconv. There is nothing wrong with IBM's implementation as far as IEEE rules go (there are few instances where IEEE says the implementation may decide if something is a hard error or not. GNU has defined a number of things as "hard error" - and call IBM iconv() buggy because of that. It is not a bug.

I stopped bothering with these discussions.

I will have to dig around a bit to see what package I "copied" this behavior from (merging libraries). Not promising anything.

But if you go back to RPM packaged tools - make sure you can uninstall as well. That was my other reason for using 'mkinstallp'. Too often I could not uninstall something. To go back I would have to reinstall AIX (these are the times I discovered issues).

And switching to Linux does not make issues like this magically disappear. I am working with Linux (much less than with AIX) - but get confronted with sudden dependencies that cannot be resolved - automatically.

Bottom line: getting packaging right 100% of the time is very hard. Probably why there is a team of people working on packaging things.

I am sharing the fruits of my "study". Of course I am saddened if you consider them unfit for purpose - but when you have programs that insist on the same library name (the .a file) but have different member names - you have to accept 'merge' or never use the other.

Holidays now - so I will not be doing much in the coming weeks - but I do try and check daily for issues and/or feedback. But it is, as so many things in OSS - ASIS "warranty"

Happy Holidays!

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1039
  • Karma: +0/-0
Re: iconv and simlink
« Reply #6 on: December 27, 2016, 12:32:17 PM »
As you can see (read: http://www.rootvg.net/content/view/710/169/) - I have been thinking about this - and I guess I should hunt for an example of RPM (still) overwriting an installp file - so that uninstalls are no longer possible.

An easy example of what cannot be uninstalled (but not yet why) is to follow Nigel's steps (and IBM's recommended process) for installing cloud-init: https://www.ibm.com/developerworks/community/blogs/aixpert/entry/PowerVC_deploying_AIX_with_Cloud_Init?lang=en - and skip down to part 2

Compare this with my install process (that can be uninstalled!) at: http://www.aixtools.net/index.php/cloudinit

owlmind

  • Jr. Member
  • **
  • Posts: 6
  • Karma: +0/-0
Re: iconv and simlink
« Reply #7 on: January 05, 2017, 06:59:07 AM »
Your packages much simpler to install, especially complex things, like python.
However aix support yum repo now http://chmod666.org/index.php/enhance-your-aix-packages-management-with-yum-and-nim-over-http/

Michael

  • Administrator
  • Hero Member
  • *****
  • Posts: 1039
  • Karma: +0/-0
Re: iconv and simlink
« Reply #8 on: January 05, 2017, 08:10:19 AM »
Thanks for the link.

IMHO - rpm is the wrong way to go - because of the way it can interfere with what installp has done. Many .spec files are not AIX aware.

HOWEVER, if IBM is really going to support open-source - great. I am just confused that I have been 'warned' to not do things because IBM legal 'wants control' - my paraphrase.

Lucky me - for now at least - I do not work for IBM USA (although I do work for IBM - reminder: aixtools and rootvg are not supported by IBM!) and my managers have not found my activities with rootvg.net and aixtools.net as a "conflict of interest". That said, it is a new year - maybe it is time to close shop and leave.

Sigh! :)

Further, I noticed the date of the article - last July. Once concern since then is that the new yum only works with the IBM packaged stuff - and IBM (legal) has been very slow to get new packages out. (i.e., the new yum is not compatible with the packaging from perzl and/or bull (which is usually just a repackaging of perzl packaging).

I do not care about RPM or INSTALLP aka BFF. I do care about stability.

And I wonder - will IBM package python (as I am starting to starting 'today' with python-2.7.13 - will use: aixtools.python (for python2) and aixtools.python3-3.X.Y.Z for python3) in a way that both python2 and python3 can co-exist side-by-side.

That mine could not before - is my fault - calling both python2 and python3 aixtools.python.

I hope IBM provides what you need - as soon as you need it.

Michael
« Last Edit: January 05, 2017, 08:24:09 AM by Michael »