phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identifying apps stati - Was: Re: [phpGroupWare-developers] Status o


From: Olivier Berger
Subject: Re: Identifying apps stati - Was: Re: [phpGroupWare-developers] Status of the Debian packaging of phpGroupware
Date: Fri, 22 Feb 2008 11:09:54 +0100

Le vendredi 22 février 2008 à 20:42 +1100, Dave Hall a écrit :
> On Fri, 2008-02-22 at 09:52 +0100, Olivier Berger wrote:

> > OK, then I'd like to propose the following packaging for Debian :
> > 
> > phpgroupware = phpgroupware-core + addressbook, calendar, notes, and email
> > where :
> > phpgroupware-core = phpgwapi, setup, admin and preferences
> > 
> 
> I think the debian packaging should reflect the upstream packaging,
> which is changing for 0.9.18

OK.

And as we are preparing "brand new" packages (new for Debian, at least,
since previous ones were removed) for 0.9.16, we can try and start over
with this new packaging scheme. 

Btw, I think we should package something called phpgroupware-0.9.16(-*)
instead of only phpgroupware(-*), so we'll be ready for adding phpgw
0.9.18 without much mess, and keep both version in Debian... hopefully
we can make it for next Debian stable with phpgw-0.9.16-core at least.

> 
> We will have phpgroupware-core:
> 
> * phpgwapi
> * setup
> * admin
> * preferences
> * manual - most likely
> * addressbook
> * calendar
> * 1 email module - TBA which one
> * filemanager
> * notes
> * todo
> 
> Then there will individual tarballs for each of the maintained and
> supported modules.  These would be released on a different release cycle
> to the core.
> 

OK, that means we could have an pseudo upstream phpgw-0.9.16-core.tgz
which derives some phpgw-0.9.16-core-core with only phpgwapi, setup,
admin and preferences and the rest in phpgw-0.9.16-core, following my
previous scheme...

OK, that sound confusing, I agre ;) : why not something like -core-base
instead of core-core. That would give (for 0.9.16) :
phpgroupware-core.tgz leads to :
 * phpgroupware-core-base.deb :
  * phpgwapi
  * setup
  * admin
  * preferences
 * phpgroupware-core-manual.deb
 * phpgroupware-core-addressbook.deb
 ...

phpgroupware-core.tgz would basically be parts of phpgw.tgz for 0.9.16
if this is allowed by Debian Reference.

I'm insisting on the core-base, since it's basically all we need in
PicoForge to use phpgw infrastructure not for "groupware" needs ;)

> The plan for 0.9.18 goes something like this
> 
> The core is released, with bug and security fixes as needed.
> 
> The non core modules will have a regular release window to release as
> part of a proper release push from the project.  So for example. there
> are some bugs in a module the developer can push a . release.  Or if
> they have a stack of new features, push a new major revision, without
> having to wait for a new core release.
> 
> > Then there would be the option of installing only the 'application
> > server', i.e. only an empty placefolder to add custom applications, by
> > installing phpgroupware-core.
> 
> For 0.9.18 to really be functional you will need phpgroupware-core as
> outlined above.

OK, but not for 0.9.16 ;)

> 
> > But one could for instance also install 'phpgroupware', which would
> > install the basic groupware apps.
> > 
> > phpgroupware-core would recommend phpgroupware, but without making it
> > mandatory.
> > 
> > This should help have something more manageable for the packager, in
> > case of security issues on the API+stuff without caring for maintenance
> > of the rest of the individual apps, IMHO.
> 
> As it is all being packaged anyway, I don't think it makes much difference.
> 

Well... it may be no longer fully packaged for Debian unless someone
volunteers... basically packaging -core would already be good for a
start for Christian and me, I'm afraid.

> > One consequence is that we may base the packaging on two different set
> > of source packages, : phpgroupware-core and phpgroupware-groupware-apps
> > (or any other name meaning : addressbook, calendar, notes, and email)
> > maybe, in which we woud have splitted your sources. This would help
> > manage the security fix releases on one of each packages independently,
> > maybe.
> 
> I would need to check the debian packaging guidelines, but AFAIK, if
> packages are all derived from the same upstream source (such as the
> official core tar/bz/zip ball) they would all be built from the same
> source in debian, so it wouldn't really change things in terms of
> security released for debian.  Look at X Windows, one typo change in the
> source debian/ the whole package needs to be rebuilt. :)

We definitely need to check that... but on the other hand Debian QA
people insisted on bad packaging of phpgw, need to split it, etc... so
in good logic there shouldn't be problems on splitting existing upstream
tarball, as long as we keep being good citizens copyright-wide. I'm sure
sponsors will be glad to look at our RFS when packages are ready, and
start appropriate trolls ;)

Best regards,
-- 
Olivier BERGER <address@hidden> (*NEW ADDRESS*)
http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM / TELECOM & Management SudParis (http://www.it-sudparis.eu/), 
Evry






reply via email to

[Prev in Thread] Current Thread [Next in Thread]