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