Hi,
Matthias Klose wrote:
> Rene Engelhard writes:
> > Hi,
> >
> > Matthias Klose wrote:
> > > no, I don't care anymore about "delays" in NEW after having to wait
> > > about 12 or 13 days for a new binary with the last gcj-4.2 upload. If
> > > ftp-masters did make the decision that new binary packages have to
> > > land in NEW, then they should process them in time. What do you gain
> > > by blocking transitions of depending packages by weeks? Is this really
> > > wanted?
> >
> > And what do you gain from making them (== packages build-deping on
> > java-gcj-compat-dev) unbuildable (on clean sids, and - more importantly -
> > on the buildds)?
>
> no, it doesn't change anything, as the new gcj packages did conflict
> with the new java-gcj-compat. you yourself did point out that in an
> earlier bug report and did request that conflict. so things are not
Correct.
> worse than before.
Yes, not worse that what happened after your uploads anyway.
Worse, thogh, than how you could have handled it.
AFAIS, You could have uploaded gc{c,j}-4.2 end ecj. Wait for NEW.
java-gcj-compat-dev so far didn't do stuff with gcj-4.2 so it would not have
affected it.
And after they got out of NEW do what you did (change the default g{i,c}j,
upload gcc-defaults, java-gcj-compat-dev, etc and upload them...)
No installability problems because something was in NEW, only temporary
uninstallability until everyting is uploaded, built and available with the
right versions. That's normal version-skew in unstable and not "I uploaded
something depending on something I know of that it isn't in sid".
What happened though, is uploading something to unstable which is
knowingly not installable and which will only be installable when ecj
clears NEW - whenever that happens.
(In which case I obviously and of course would not have filed a bug
like #439670 but would have waited for the new versions being there - or
fetching them from incoming if needed).
Oh, and yes, i do not like the long NEW processing times at all, too,
but that's not a reason to break all packages in sid build-depending on
java-gcj-compat-dev if you can avoid it.
Gr�gards,
Ren�-
.''`. Ren�ngelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' rene@debian.org | GnuPG-Key ID: 248AEB73
`- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Attachment:
signature.asc
Description: Digital signature