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

Re: [Zope] A few questions...



On Wed, Jan 26, 2005 at 10:13:04AM +0100, Fabio Tranchitella wrote:
> Il giorno mar, 25-01-2005 alle 15:33 -0700, Joel Aelwyn ha scritto:
> > [ Mail-Followup-To set; please *do* Cc me, as I do not currently          ]
> > [ subscribe to the -python list, though it appears to be the proper place ]
> > [ for Zope discussions, at least from what I can find in the archives.    ]
> > [ Please redirect me if somewhere else is more appropriate.               ]
> > 
> > So I have relatively recently taken over a Zope package, and while it is
> > now in (basically) good shape, there are a couple of technical points I
> > want to clear up to make sure I'm doing it right, since what I can find on
> > the mailing list archives isn't entirely conclusive.
> 
> I think the right place for your email is the mailing list of zope
> debian packages developers [1], but the list seems to be almost dead.

Allright.

> > 1) Is it proper (assuming that the package works under both Zope 2.6 and
> >    Zope 2.7) to Depend on 'zope | zope2.7'? It seems like it should be, but
> >    I wanted to double-check.
> 
> IMHO the dependency should be "zope2.7 | zope", so the newer version
> will be automatically installed if needed.

Hmmm. I got the (quite possibly mistaken) impression that the 'zope2.7'
package was intended as a temporary situation, rather than 'zope' being
permanently stuck at 2.6 and all future Zope packages adding a new source
package. I mean, I could see 'Zope3', given that a major revision is
allowed to break all sorts of things, but why split 2.7 into a separate
package?

> > 2) Usage of debconf templates. The debconf manual (and the maintainer)
> >    seem to think that every package which uses the shared Zope restart
> >    template needs to provide an identical copy. 
> 
> My opinion on this issue is that for zope packages you do not use the
> shared template, just read its value in debian/postinst. For this
> reason, you haven't (and you shouldn't) provide the template: you'll
> never ask the user for that question so providing the template have
> really no sense, this just create additional work for the translators.
> 
> Here an example from one of my packages:
> 
> $ cat zope-cmfphoto-0.5.0/debian/postinst | grep "shared/zope"
>         db_get "shared/zope/restart" || true
> 
> If db_get fails (the package zope isn't installed, or the template
> hasn't been initialized, or something else) the "or true" prevents the
> maintainer script to return a bad exit code.

Believe me, I understand the rationale. My issue is that this rationale
isn't, formally, supported by debconf. So I guess I should CC it to the
debconf maintainer for clarification.

> So, why for the hell you provide the template in your package? :)

Solely because "that's the requirement according to the debconf manual
and maintainer".

> After this, I maintain a lot of zope packages. Packaging this type of
> software is quite easy, and often it is a repetitive job. For this
> reason I'd like to see a dh_zope debhelper script, so the packages 
> (at least the easy ones) could get rid of their templates and their
> maintainer scripts. I know that Luca De Vitis started working on it, 
> and I tried to mail him but I haven't received any answer so far. 
> His last upload to zope package is on 2004, February. Does anyone 
> know if he is still around?

No argument here; some sort of dh_zope would be very handy, given that most
of the "weird" bits of packaging I had to do were Zope specific (things
like symlinks to move static images out of /usr/lib, or dealing with the
debconf stuff) that could easily be wrapped up in a dh_zope utility.
-- 
Joel Aelwyn <fenton@debian.org>                                       ,''`.
                                                                     : :' :
                                                                     `. `'
                                                                       `-

Attachment: signature.asc
Description: Digital signature


Reply to: