(Migrated) installation under ubuntu 14.04

(This message has been automatically imported from the retired mailing list)

Hello.

Here: https://gist.github.com/njordr/8200fc5b1bbee4c08df5 you can find the
modified script to create a deb package for ubuntu 14.04.

build-zato-deb.sh is for zato-duild repository
install.sh is for zato repository, branch support/1.1

I tried them executing every step one by one. They work well. Then I tried
the deb package on another server and it run correctly.
If you like them and you will merge with official repos, let me know so I
can test a complete running :slight_smile:

Cheers

Hi Giovanni,

On 30/04/14 13:17, Giovanni Colapinto wrote:

Hello.

Here: https://gist.github.com/njordr/8200fc5b1bbee4c08df5 you can find
the modified script to create a deb package for ubuntu 14.04.

build-zato-deb.sh is for zato-duild repository
install.sh is for zato repository, branch support/1.1

I tried them executing every step one by one. They work well. Then I
tried the deb package on another server and it run correctly.
If you like them and you will merge with official repos, let me know
so I can test a complete running :slight_smile:

I had a look at your modifications and gave them a try in an ubuntu
14.04 fresh install.

It looks ok, and the deb file is properly build, but I found small issue
which I had to fix in line 85 of build-zato-deb.sh script:

It ends like this:

$SIZE/g" >$CURDIR/BUILDROOT/zato-$ZATO_VERSION-$PACKAGE_VERSION_$ARCH/DEBIAN/ control

While it should be (if I’m not wrong…):

$SIZE/g" >$CURDIR/BUILDROOT/zato-$ZATO_VERSION-$PACKAGE_VERSION_$ARCH/DEBIAN/control

A part from that, everything worked like a normal build in ubuntu 12.04 using the repo version unmodified.
And I also tested the generated .deb installing it and creating a quickstart cluster: Everything seems fine.

However, I have a question about the changes in rows 58-62:

  • cd $ZATO_TARGET_DIR/code
  • cp …/LICENSE.txt .
  • cp …/licenses_3rd_party.txt .
  • cd $ZATO_TARGET_DIR
  • shopt -s dotglob
  • mv code/* .
  • shopt -u dotglob
  • rm -Rf code

What’s the reason of these changes?
I’m not saying that they are wrong, it’s just that I see no reason for this change.

Regards,
Carles

Noooooooooooo, I forgot to fix it!!! I’ve seen the issue and fix it, but I
committed on gist the old code :frowning:

About rows from 58 to 62: they fix a strange behaviour. If I don’t use
them, the deb package install the code in /opt/zato/1.1/code/… and
nothing works :frowning:

Cheers

On Wed, Apr 30, 2014 at 7:07 PM, Coeuz coeuz@coeuz.net wrote:

Hi Giovanni,

On 30/04/14 13:17, Giovanni Colapinto wrote:

Hello.

Here: https://gist.github.com/njordr/8200fc5b1bbee4c08df5 you can find
the modified script to create a deb package for ubuntu 14.04.

build-zato-deb.sh is for zato-duild repository
install.sh is for zato repository, branch support/1.1

I tried them executing every step one by one. They work well. Then I
tried the deb package on another server and it run correctly.
If you like them and you will merge with official repos, let me know so I
can test a complete running :slight_smile:

I had a look at your modifications and gave them a try in an ubuntu 14.04
fresh install.

It looks ok, and the deb file is properly build, but I found small issue
which I had to fix in line 85 of build-zato-deb.sh script:

It ends like this:

$SIZE/g" >$CURDIR/BUILDROOT/zato-$ZATO_VERSION-$PACKAGE_VERSION_$ARCH/DEBIAN/
control

While it should be (if I’m not wrong…):

$SIZE/g" >$CURDIR/BUILDROOT/zato-$ZATO_VERSION-$PACKAGE_VERSION_$
ARCH/DEBIAN/control

A part from that, everything worked like a normal build in ubuntu 12.04
using the repo version unmodified.
And I also tested the generated .deb installing it and creating a
quickstart cluster: Everything seems fine.

However, I have a question about the changes in rows 58-62:

  • cd $ZATO_TARGET_DIR/code
  • cp …/LICENSE.txt .
  • cp …/licenses_3rd_party.txt .
  • cd $ZATO_TARGET_DIR
  • shopt -s dotglob
  • mv code/* .
  • shopt -u dotglob
  • rm -Rf code

What’s the reason of these changes?
I’m not saying that they are wrong, it’s just that I see no reason for
this change.

Regards,
Carles

Hi Giovanni,

El 30/04/14 20:36, Giovanni Colapinto ha escrit:

About rows from 58 to 62: they fix a strange behaviour. If I don’t use
them, the deb package install the code in /opt/zato/1.1/code/… and
nothing works :frowning:

Then I’m afraid that your fix didn’t do the trick completely, since it
works, but only when the version “1.1” is used. Any other version string
makes it fail. :frowning:

To be more precise, when I built the package for the first time I used a
custom version number “1.1-csala”, and did it both in 14.04 and 12.04,
to compare the results.
And I had exactly this problem which you described: The .deb was built
properly in both 12.04 and 14.04, but when I installed it the code was
placed in /opt/zato/1.1-csala/code while the PATH in /opt/zato/.profile
pointed at /opt/zato/1.1/bin, so nothing worked (changing the PATH made
it work, though).

Later on, I rebuilt both packages using version “1.1” and in that case
the code was placed in the right folder (/opt/zato/1.1).
So, your trick worked but only if 1.1 is used, which means that we need
to take a closer look and identify how the version string is involved in
these differences.

Regards,
Carles

Thank you for your feedback Carles.

Tomorrow I will go deep in this issue :slight_smile:

Bye

On Thu, May 1, 2014 at 11:16 AM, Coeuz coeuz@coeuz.net wrote:

Hi Giovanni,

El 30/04/14 20:36, Giovanni Colapinto ha escrit:

About rows from 58 to 62: they fix a strange behaviour. If I don’t use
them, the deb package install the code in /opt/zato/1.1/code/… and
nothing works :frowning:

Then I’m afraid that your fix didn’t do the trick completely, since it
works, but only when the version “1.1” is used. Any other version string
makes it fail. :frowning:

To be more precise, when I built the package for the first time I used a
custom version number “1.1-csala”, and did it both in 14.04 and 12.04, to
compare the results.
And I had exactly this problem which you described: The .deb was built
properly in both 12.04 and 14.04, but when I installed it the code was
placed in /opt/zato/1.1-csala/code while the PATH in /opt/zato/.profile
pointed at /opt/zato/1.1/bin, so nothing worked (changing the PATH made it
work, though).

Later on, I rebuilt both packages using version “1.1” and in that case the
code was placed in the right folder (/opt/zato/1.1).
So, your trick worked but only if 1.1 is used, which means that we need to
take a closer look and identify how the version string is involved in these
differences.

Regards,
Carles

On 04/30/2014 01:17 PM, Giovanni Colapinto wrote:

Here: https://gist.github.com/njordr/8200fc5b1bbee4c08df5 you can find the
modified script to create a deb package for ubuntu 14.04.

Thanks Giovanni,

I haven’t tried it yet but a thing I’d like to ask is - can we please
keep the ‘code’ directory around, i.e. /opt/zato/1.1/code?

For better or worse this is how it has been so far and I think it
wouldn’t look too nice if only the package for Ubuntu 14.04 didn’t have it.

thanks a lot,

On 04/30/2014 01:17 PM, Giovanni Colapinto wrote:

Here: https://gist.github.com/njordr/8200fc5b1bbee4c08df5 you can find the
modified script to create a deb package for ubuntu 14.04.

Thanks Giovanni,

I haven’t tried it yet but a thing I’d like to ask is - can we please
keep the ‘code’ directory around, i.e. /opt/zato/1.1/code?

For better or worse this is how it has been so far and I think it
wouldn’t look too nice if only the package for Ubuntu 14.04 didn’t have it.

thanks a lot,

If this is the situation, it makes sense to understand if the standard must
be to have zato root directory under /opt/zato//code and modfiy
$PATH as needed. I moved all from code for my way of thinking and to
respect PATH variable, but maybe this is not the right way :slight_smile:

Cheers

On Thu, May 1, 2014 at 9:15 PM, Dariusz Suchojad dsuch@zato.io wrote:

On 04/30/2014 01:17 PM, Giovanni Colapinto wrote:

Here: https://gist.github.com/njordr/8200fc5b1bbee4c08df5 you can find
the
modified script to create a deb package for ubuntu 14.04.

Thanks Giovanni,

I haven’t tried it yet but a thing I’d like to ask is - can we please
keep the ‘code’ directory around, i.e. /opt/zato/1.1/code?

For better or worse this is how it has been so far and I think it
wouldn’t look too nice if only the package for Ubuntu 14.04 didn’t have it.

thanks a lot,


Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python

On 05/02/2014 09:21 AM, Giovanni Colapinto wrote:

If this is the situation, it makes sense to understand if the standard must
be to have zato root directory under /opt/zato//code and modfiy
$PATH as needed. I moved all from code for my way of thinking and to
respect PATH variable, but maybe this is not the right way :slight_smile:

Hm, I’m not sure - but to some extent I think Zato’s situation is
similar to that of Postgres - there can be multiple environments under
one OS and the OS needs to support multiple versions of Postgres,
including stuff in /usr, /etc and so on.

Some people use Docker and they place Zato in yet another locations so
for them it won’t matter if there is a version number or not.

For people who run only one set of Zato binaries - I guess it won’t
matter because it’s only that one install?

And for people who already have 1.1 but will want to give 2.0 a try,
first on a dev box, I gather they’d enjoy being able to test it
side-by-side? The ones I spoke with said they would.

But I’m not sure what you mean by respecting the PATH variable? You mean
that without the version number it’s always one place, i.e.
/opt/zato/bin so whatever is in there is always on PATH and otherwise
one need to update it for 1.1, 2.0 and otherwise?

No, I mean that PATH variable shipped with deb package heading to
/opt/zato//bin, but deb package by default install all files under
/opt/zato//code/
Leave version is very useful, I want to understand if is better to move or
copy all files from code directory or if is better to leave all files in
code directory and mopdify PATH variable

I hope I explained :slight_smile:

On Fri, May 2, 2014 at 9:41 AM, Dariusz Suchojad dsuch@zato.io wrote:

On 05/02/2014 09:21 AM, Giovanni Colapinto wrote:

If this is the situation, it makes sense to understand if the standard
must
be to have zato root directory under /opt/zato//code and modfiy
$PATH as needed. I moved all from code for my way of thinking and to
respect PATH variable, but maybe this is not the right way :slight_smile:

Hm, I’m not sure - but to some extent I think Zato’s situation is
similar to that of Postgres - there can be multiple environments under
one OS and the OS needs to support multiple versions of Postgres,
including stuff in /usr, /etc and so on.

Some people use Docker and they place Zato in yet another locations so
for them it won’t matter if there is a version number or not.

For people who run only one set of Zato binaries - I guess it won’t
matter because it’s only that one install?

And for people who already have 1.1 but will want to give 2.0 a try,
first on a dev box, I gather they’d enjoy being able to test it
side-by-side? The ones I spoke with said they would.

But I’m not sure what you mean by respecting the PATH variable? You mean
that without the version number it’s always one place, i.e.
/opt/zato/bin so whatever is in there is always on PATH and otherwise
one need to update it for 1.1, 2.0 and otherwise?

On 05/02/2014 09:47 AM, Giovanni Colapinto wrote:

No, I mean that PATH variable shipped with deb package heading to
/opt/zato//bin, but deb package by default install all files under
/opt/zato//code/

Ah gotcha.

This should be changed in that case - I can see ‘postinst’ has it
hardcoded (lines 17-18)

The line …

PATH="/opt/zato/1.1/bin:$PATH"">>/opt/zato/.profile

… should be changed to something like …

PATH="/opt/zato/ZATO_VERSION/code/bin:$PATH"">>/opt/zato/.profile

… and then in build-zato.sh’s build_deb function …

… there should be a call to sed added with the effect of updating PATH
to a proper version.

Can you add it or I should?

Btw. All the recent works on build scripts are being done by a colleague
of mine, I only add minor tweaks. So I didn’t catch earlier what the
deal with PATH was.

Ok finally we got it!!! :smiley:

I will modify the script and resubmitting it

Cheers

On Fri, May 2, 2014 at 10:04 AM, Dariusz Suchojad dsuch@zato.io wrote:

On 05/02/2014 09:47 AM, Giovanni Colapinto wrote:

No, I mean that PATH variable shipped with deb package heading to
/opt/zato//bin, but deb package by default install all files
under
/opt/zato//code/

Ah gotcha.

This should be changed in that case - I can see ‘postinst’ has it
hardcoded (lines 17-18)

https://github.com/zatosource/zato-build/blob/master/deb/package-base/DEBIAN/postinst

The line …

PATH="/opt/zato/1.1/bin:$PATH"">>/opt/zato/.profile

… should be changed to something like …

PATH="/opt/zato/ZATO_VERSION/code/bin:$PATH"">>/opt/zato/.profile

… and then in build-zato.sh’s build_deb function …

https://github.com/zatosource/zato-build/blob/master/deb/build-zato.sh

… there should be a call to sed added with the effect of updating PATH
to a proper version.

Can you add it or I should?

Btw. All the recent works on build scripts are being done by a colleague
of mine, I only add minor tweaks. So I didn’t catch earlier what the
deal with PATH was.

On 05/02/2014 10:19 AM, Giovanni Colapinto wrote:

I will modify the script and resubmitting it

Thanks, and now that I look at it again it looks I’m wrong on the 'code’
part - the already existing packages don’t have it after all so the new
ones, including what is build using the scripts from zatosource-build,
should not have it either.

My bad, sorry for the confusion, I shouldn’t have introduced it.

So, to better understand, actual PATH variable is correct and I need to
move zato files outside code directory?

On Fri, May 2, 2014 at 10:36 AM, Dariusz Suchojad dsuch@zato.io wrote:

On 05/02/2014 10:19 AM, Giovanni Colapinto wrote:

I will modify the script and resubmitting it

Thanks, and now that I look at it again it looks I’m wrong on the 'code’
part - the already existing packages don’t have it after all so the new
ones, including what is build using the scripts from zatosource-build,
should not have it either.

My bad, sorry for the confusion, I shouldn’t have introduced it.

On 05/02/2014 10:38 AM, Giovanni Colapinto wrote:

So, to better understand, actual PATH variable is correct and I need to
move zato files outside code directory?

Let’s stick to /opt/zato//bin - this is what the already
released packages have.

In other words, my tinkering with build scripts before I put them on GH
introduced the superfluous ‘code’ part. I mistakenly thought it was the
other way around - that the packages released had ‘code’ but postinst
didn’t have it, but I was wrong - let’s have /opt/zato//bin
everywhere :slight_smile:

This means that postinst’s PATH is correct.

thanks a lot again,

Hi

I’ve updated gist https://gist.github.com/njordr/8200fc5b1bbee4c08df5

Now It can bue used even with custom versions :slight_smile:

Cheers

On Fri, May 2, 2014 at 10:45 AM, Dariusz Suchojad dsuch@zato.io wrote:

On 05/02/2014 10:38 AM, Giovanni Colapinto wrote:

So, to better understand, actual PATH variable is correct and I need to
move zato files outside code directory?

Let’s stick to /opt/zato//bin - this is what the already
released packages have.

In other words, my tinkering with build scripts before I put them on GH
introduced the superfluous ‘code’ part. I mistakenly thought it was the
other way around - that the packages released had ‘code’ but postinst
didn’t have it, but I was wrong - let’s have /opt/zato//bin
everywhere :slight_smile:

This means that postinst’s PATH is correct.

thanks a lot again,


Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python

On 05/02/2014 05:04 PM, Giovanni Colapinto wrote:

I’ve updated gist https://gist.github.com/njordr/8200fc5b1bbee4c08df5

Good stuff - I’ve just tested it on 14.04 and 12.04, everything went
smoothly.

Many thanks to you and Carles for this contribution!