[Fusionforge-general] Plans for packaging
gforge at free.fr
gforge at free.fr
Fri Apr 25 10:11:55 CEST 2014
----- Mail original -----
> De: "Sylvain Beucler - Inria" <sylvain.beucler at inria.fr>
> À: "fusionforge-general" <fusionforge-general at lists.fusionforge.org>
> Envoyé: Jeudi 24 Avril 2014 11:12:08
> Objet: [Fusionforge-general] Plans for packaging
> Last Friday, Christian mentioned he'd work on install-ng just before
> he left.
> Then packaging was discussed again a little bit. Let's recap.
> - Beuc recommends (re)implementing the packaging as a thin layer over
> set of common Makefile's, to be shared by Debian, RedHat, and others.
> > Question: Would that mean to merge back packaging in master ?
> Note that 90% packaging is already in master in the packaging/ dirs.
> These would be replaced by the Makefiles, so in master.
> What was moved out of master is deb-specific/, which (independently
> of the packaging) we've been working on merging / de-duplicating.
> The Debian packaging is traditionally kept separate to accommodate
> some Debian tools, and to allow branching depending on target (e.g.
> stable, unstable, backports).
> However, having to merge the upstream and debian repos several times
> a day is a pain, so I wouldn't mind getting rid of the debian
> intermediary repo somehow, especially if the packaging is nearly
> identical on all targets.
> .spec files are currently in master and can stay there I think.
+1 not to duplicate repositories
about the reason I made this packaging, the initial goal was to build both
debian and spec reusing the same description.
As i never finished this, i don't mind if someone refactor/remove this, but I would suggest
as much as possible to have a single description, included at least for plugins
in some kind of getdescription method, that could be used everywhere, not to duplicate
description, and possibly translations.
> - Beuc willing to check if Ubuntu support for FusionForge .deb
> (reputably broken) is simple to fix, so we can avoid writing a
> about it in the IRC channel topic. nerville going to remove said
> warning anyway.
I think that mostly the problem is link on config variation, that appears
regularilly in ubuntu, a cool stuff would be to have a fusionforge
charm (https://jujucharms.com/) too
One interesting stuff in these charm is how database link hook is made
especially that the database is filled when plugged, in a common way
and that database replication is in some way auto handled.
> > Question: Wouldn't be that difficult to add ubuntu builds in the
> > bot, LTS only ?
> I guess not, though OTOH the buildbot seems quite busy and it's
> annoying enough already to wait up to several hours to see if the
> latest commits pass the tests.
then I would suggest to look how to use jenkins slaves to //
> > Christian: Massively cleaning the now quite unreadable makefile, if
> > no objection.
> (do you mean "install-ng"?)
I mean Makefiles*
> I'd recommend detecting features rather than OS (autoconf philosophy)
> - e.g. assign $apache_user/$apache_group once rather than writing
> multiple install2_files_$distro functions.
> If the Makefiles support DESTDIR, they can be reused by packaging, so
> let's do that too.
> Post-install scripts can be installed in the system and run by the
> packaging on install.
I fully agree, to reuse as much as possible common install code, in
install-ng, debian and spec
especially because à the end rules file could be really very very simple
do you suggect a Makefile / plugin ?
I started some work on tuleap debian packaging, Raphael Hertzog made some good work there
and I'll probably try to share the same approach on both side.
> Fusionforge-general mailing list
> Fusionforge-general at lists.fusionforge.org
More information about the Fusionforge-general