Le mercredi 16 avril 2008 à 17:28 +0200, Alexander Klauer a écrit :
> Olivier Berger:

> > Le mercredi 16 avril 2008 à 16:19 +0200, Alexander Klauer a écrit :
> > > # dpkg -l | grep phpgroupware
> > > rc  phpgroupware                         0.9.16.012+dfsg-1               
> > > web based groupware system written in PHP
> >
> > Strange... it seems the phpgroupware package isn't installed... as an
> > epoch 1 package.
> 
> Correct. The phpgroupware version 0.9.16.012+dfsg-1 (non-epoch) package was 
> installed for quite some time, and then marked as to-be-removed by aptitude 
> for unsatisfied dependencies two days ago (this happens sometimes, as new 
> packages appear in lenny and their dependencies change);

I'm surprised that it would have been to be removed, instead of upgraded
by the new phpgroupware package (yes, the transition one).
Maybe you chose to remove it instead of upgrading it ?

>  the current version 
> of the phpgroupware binary package is only transitional anyway, it being 
> replaced by phpgroupware-0.9.16.

Hmmm... I'm afraid it's not exactly that. But it's a bit too complex maybe :

>From the description of the new phpgroupware package :
 This empty package is a transition package to the new
 phpgroupware-0.9.16-* (epoch 1) packages for phpGroupware.
 .
 See package phpgroupware-0.9.16 instead.
 .
 Note that all phpgroupware apps previously packaged (epoch 0) may no
 longer be available.
 .
 After successful upgrade, this package can be safely removed.

Thus, it's meant to be upgraded first, and then maybe afterwards
removed, as the last sentence explains it.
The problem seems to be that such procedure can be avoided... and I
couldn't find a way to avoid that without adding too many dependencies
for cases of new installations drom scratch.
It was difficult to do it any other way I'm afraid :(

Is this clear ? 

>  So I selected phpgroupware-0.9.16-calendar, 
> phpgroupware-0.9.16-manual and phpgroupware-0.9.16-doc for installation. All 
> the other packages were selected by aptitude to satisfy dependencies. 
> phpgroupware-0.9.16 was NOT among them. 

Right : it's only a meta package now. This one is not really necessary
now maybe... but it prepares a path for appearance of a future
phpgroupware-0.9.18 package some day. (Both would conflict with
eachother probably, being in the distro at the same time)

> Maybe a missing dependency in the 
> package?

No. The one which others depend on is now phpgroupware-0.9.16-core-base.
It's the one which now provides the debconf scripts and stuff for
"Debianisation" of phpGW (which used to be provided by the
"phpgroupware" package).

>  Installing this package would pull in the phpgroupware-0.9.16-core 
> package, which in turn would pull in a lot of other phpgroupware modules 
> through Recommends.

Yes indeed. The idea is that phpgroupware-0.9.16-core is too a meta
package (depending on all "core groupware modules").

> 
> > I'd expect to see phpgroupware (1:0.9.16.012+dfsg-2) there (see
> > http://packages.debian.org/lenny/phpgroupware) ...
> >
> > Maybe that explains the issue that you had ?
> 
> I think you mean phpgroupware-0.9.16, not phpgroupware. Well, maybe yes, but 
> then phpgroupware-0.9.16-calendar etc. should Depends on phpgroupware-0.9.16 
> somewhere down the chain.
> 

No, as I explained above.

I hope the picture is a bit clearer now... still a schema may be
necessary for a better explanation ? ;)

> > I'm not exactly sure what "rc" means... removed+unconfigured ?
> 
> Package removed, configuration files still installed.
> 

Thanks. That's what I guessed it was.

> > > (configuration files of the old phpgroupware still exist; maybe that's
> > > the source of the problem). I also tested the new installation with a
> > > test account. Everything worked just fine.
> >
> > So I'd say the bug may be fixed then.
> 
> It worked just fine until the reboot. I cannot rule out that I inadvertently 
> tested the "old" installation (or parts of it) somehow before the reboot. In 
> any case, aptitude had finished the installation, of course, before I began 
> testing.
> 
> > Do you have an idea of what happened during the upgrade (which apt
> > frontend used, also) ?
> 
> aptitude, see above.
> 
> > Maybe you should reinstall the "phpgroupware" package (version
> > 1:0.9.16.012+dfsg-2), and maybe remove it once it's installed OK, just
> > for the sake of a clean system ?
> 
> I'm quite content that it works now. From what you told me above, my guess is 
> a Depends or a Replaces was missing somewhere. If it's an issue of the 
> phpgroupware -> phpgroupware-0.9.16 transition only, this bug may be quite 
> irrelevant in testing, but please make sure the etch->lenny transition works 
> flawlessly, once lenny becomes stable. Thank you!
> 

Yes, that's a concern we have with this upgrade process... Hmmm...

I guess we may need a second think about all this, and your comments
were definitely valuable. Maybe I devised the dependency scheme for the
new packages with a bit too many constraints at the same time...

I'll try and do more upgrade tests, but I think it may be difficult to
improve the situation now.

If you have any suggestions, in response to this, it would be much
welcome too.

Best regards,
-- 
Olivier BERGER <[EMAIL PROTECTED]> (*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