Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging process #174

Closed
Seb-Solon opened this issue Aug 13, 2015 · 21 comments
Closed

Packaging process #174

Seb-Solon opened this issue Aug 13, 2015 · 21 comments

Comments

@Seb-Solon
Copy link
Contributor

Hi,

I'm trying to centralize talk we had about how packaging of Alignak will be implemented.

As far as I remember we stayed on 1 branch for packaging type. Like rpm / debian. So that we don't have packaging file in master/develop.

I can't remember the pros cons of that.

Linked to #91 (remove for fedora maybe)

@Seb-Solon Seb-Solon mentioned this issue Aug 13, 2015
14 tasks
@ddurieux
Copy link
Contributor

We don't have decided to add packaging files (deb, rpm, bsd...) in an other repository?

@Seb-Solon
Copy link
Contributor Author

Branch / repo is basically the same (not with the code)

@titilambert
Copy link
Member

in this case, branch means detached branch ... a new repo could be easier ?
In this repo/branch, there will be: files and folder used for packaging (spec files, debian, ...)
And a tarball of Alignak master.
What do you think ?

@Seb-Solon
Copy link
Contributor Author

Yeah a repo packaging with branch debian / rpm could be great no?

@ddurieux
Copy link
Contributor

A branch or a folder for each packaging system (prefer folder because it's more easier to read)

@gst
Copy link
Contributor

gst commented Aug 24, 2015

Sorry but don't remember too the talks we had about this..

and sorry twice but I dislike the idea to create yet another repository for this, why not have a folder named 'packaging' in our top and in it have subfolders : debian, fedora, redhat, ubuntu (no this is mean for real distribution) and so on ..

were there some cons about this possibility ?

@hvad
Copy link
Contributor

hvad commented Aug 24, 2015

Hi,

I begin work to make rpm for fedora/epel and i think we just need source for that work correctly ;-).

You can make debian directory on that repository and create a spec file for fedora/epel.

But the main jobs is to work with systemd ^^.

See you soon on irc

@gst
Copy link
Contributor

gst commented Aug 24, 2015

related: #180

@titilambert
Copy link
Member

The packaging is already done on surveil project... see here: https://github.com/surveil/surveil-packaging/blob/centos/alignak/alignak.spec

@Seb-Solon
Copy link
Contributor Author

First spec draft done on alignak-packaging.

Links to help : https://fedoraproject.org/wiki/How_to_create_an_RPM_package, https://fedoraproject.org/wiki/Packaging:RPMMacros

Macro list are very useful when you look for a specific file.

@hvad
Copy link
Contributor

hvad commented Sep 18, 2015

Hi,

i known because i use everyday ^^. See ->
http://paste.fedoraproject.org/269102/17308144

Bye

2015-09-18 22:37 GMT+02:00 Sébastien Coavoux notifications@github.com:

First spec draft done on alignak-packaging.

Links to help :
https://fedoraproject.org/wiki/How_to_create_an_RPM_package,
https://fedoraproject.org/wiki/Packaging:RPMMacros

Macro list are very useful when you look for a specific file.


Reply to this email directly or view it on GitHub
#174 (comment)
.

David Hannequin

@hvad
Copy link
Contributor

hvad commented Sep 19, 2015

@Seb-Solon
Copy link
Contributor Author

Ok first working file is done. We have to agree on some points :

  • Package structure : I'm for one alignak-common and one alignak-doc packages. We could split by daemon but it's not really worth it and I'm afraid of conflicts. Two package will provide the same files (python files)
  • Install path for python binaries : In the draft it's /usr/bin, we could argue on /usr/sbin
  • Requirements : I'm not sure for python-imporlib. Maybe we will need some if to add it to requirement. I'm afraid recent (f22) distro will fail because the package is not installed but it's now in standard python lib
  • Init script / systemd : Another if to do? The draft copy /etc/init.d/alignak* shell scripts and /etc/default/alignak files
  • .pth file : I'm not 100% sure this is needed, I removed it in packaging

See Alignak-monitoring/alignak-packaging@806f976 and https://github.com/Alignak-monitoring/alignak-packaging/blob/master/alignak.spec . I'm not sure if I will PR on "rpm" or "fXX" branch because I'm afraid we will need several spec.

@aviau
Copy link
Contributor

aviau commented Sep 21, 2015

Init script / systemd : Another if to do?

I don't know for Fedora, but in Debian we ship both the sysvinit and systemd files. So that shouldn't be an if.

we could argue on /usr/sbin

Absolutely

I'm for one alignak-common and one alignak-doc packages

I agree.

@hvad
Copy link
Contributor

hvad commented Sep 21, 2015

Hi, my point of view :

Package structure : I'm for one alignak-common and one alignak-doc packages. We could split by daemon but it's not really worth it and I'm afraid of conflicts. Two package will provide the same files (python files)

Yes, alignak-common is good idea but i not sure for doc.

Install path for python binaries : In the draft it's /usr/bin, we could argue on /usr/sbin

It's more an habit than a rule.

Requirements : I'm not sure for python-imporlib. Maybe we will need some if to add it to requirement. I'm afraid recent (f22) distro will fail because the package is not installed but it's now in standard python lib

I think it's on standard python lib until centos 7 and fedora 20.

Init script / systemd : Another if to do? The draft copy /etc/init.d/alignak* shell scripts and /etc/default/alignak files

I prefer systemd script rule and i think we must forget sysV for Linux.

.pth file : I'm not 100% sure this is needed, I removed it in packaging

Yes

@Seb-Solon
Copy link
Contributor Author

I forgot one last thing :
The setup generate .pyc and .pyo. Fedora pacaking suggest to keep them but maybe both file for each python file is a bit overkill. I don't think wee need a .pyc and a .pyo file for a specific file. I need to look documentation/usage. If you have opinion/idea about this feel free to help me.

@gst
Copy link
Contributor

gst commented Sep 21, 2015

The setup generate .pyc and .pyo. Fedora pacaking suggest to keep them but maybe both file for each python file is a bit overkill. I don't think wee need a .pyc and a .pyo file for a specific file.

*pyc are the (pre-)compiled source files.
and *pyo are same than *pyc but for "optimized" python calls (python -O some_script.py, which actually only remove/delete the assert from the sources).

I think it's better/simpler to keep both ; that doesn't hurt at all (some kbytes used, that's all)..

why would you bother remove them, they would be anyway rebuild/regenerated where the package would be executed the first time.. normally, because if, for instance, the file system where the source is located/installed is readonly then this wouldn't be possible. I think that's exactly the goal of the pre-compile during package build : have the *pyc & *pyo (directly) available (even if readonly filesystem so) on the installed destination..

@Seb-Solon
Copy link
Contributor Author

Debian packaging is working. Waiting for review of @titilambert

@mohierf
Copy link
Contributor

mohierf commented Sep 22, 2016

What about this @Seb-Solon @titilambert @ddurieux @hvad

@mohierf
Copy link
Contributor

mohierf commented Oct 26, 2016

@Seb-Solon ? What about this now ?

@Seb-Solon
Copy link
Contributor Author

Seb-Solon commented Oct 26, 2016

See https://github.com/Alignak-monitoring/alignak-packaging for all packaging related stuff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants