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

Re: zope not making into testing: why ?



Cc'ed to -devel, hope that's okay.

On Mon, May 21, 2001 at 05:21:53PM +0200, Gregor Hoffleit wrote:
> > Looks like you understand it perfectly to me; by the looks of things
> > zope-siteaccess shouldn't be in the archive anymore?
> > (If it should, then it needs a new version uploaded afaict; otherwise,
> > it needs a bug filed against ftp.d.o asking for its removal)
> Sorry, I still don't understand.

zope-siteaccess Depends: on zope. [0]

zope, however, Conflicts: with zope-siteaccess.

Thus, installing zope into testing would break people who might want
to install zope-siteaccess. So, the testing 'bot in its conservative
paranoia refuses to do that.

There are two ways of fixing this.

One is to upload a new zope-siteaccess that works with the zope in unstable.
That mightn't be possible. If it is, the testing 'bot mighn't be smart enough
to cope with it properly, and you might have to pester me some more.

The alternative, if zope-siteaccess can't be rebuilt, or if the new zope does
everything zope-siteaccess used to do, is just to say, "well, that package
isn't useful anymore" and get it removed from the archive. You can do this
by filing a bug against ftp.debian.org.

Maybe it's easier to look at it from the other perspective: when woody's
released, what do you want? A working zope-siteaccess, no zope-siteaccess,
or a broken zope-siteaccess?

(The testing 'bot will very rarely let you choose the latter)

> zope-siteaccess is still in the pool, as an architecture-independent .deb.
> Is it necessary to remove it from the archive in order to make it possible
> that the conflicting zope package is moved into testing ? How would the
> testing code detect this ?

You need to get it removed from unstable, not the pool entirely. (ie,
it can still be in stable, and it'll stay in testing until the testing
'bot considers it safe to be removed).

The testing code notices things that aren't in unstable, so will work out
something like:

] Removed packages:
] 	zope-siteaccess (2.0.0b3-4 is in testing, but nothing's in unstable)
] Updated packages:
] 	zope (2.2.4-3 is in testing, 2.3.2-2 is in unstable)
] 
] Hmmm, can I upgrade zope without anything breaking? Nope, 
] zope-siteaccess breaks.
] 
] Hmmm, can I remove zope-siteaccess without anything breaking? Yes! Woohoo!
] 
] Hmmm, can I upgrade zope without anything breaking? Yes, I can now! Yay!

It's really a bit more complicated than that, and a lot terser, but that's
the general idea.

If you get your little subset of unstable looking how it should when
woody's ready to release, then the testing 'bot should do the rest
(and if not, pester me, and I will).

Cheers,
aj

[0] And it's a versioned depend, so it's not something that can be satisfied
    by a Provides: anywhere, so no need to look too deeply.
-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgpaStT9a1pix.pgp
Description: PGP signature


Reply to: