On Sunday 29 September 2002 09:26 pm, Ben Burton wrote: > Hmm, so I'm a little worried about the scenario where we have the CVS debs > using the maintainers' packaging (which for KDE 3.1 is not apt-gettable > AFAIK but is presumably the branch that's headed for sid), Karolina's debs > using her (somewhat different) packaging and then Yenar's woody debs using > a hybrid of the two plus his own scripts... > > I guess I'm starting to get a little nervous about upgrade paths, > propagation of packaging bugfixes (as opposed to differences in taste), > that sort of thing. > > Anyway, FWIW. Maybe I just get nervous easily. :) > > b.
No you are nervous for very good reason. What is the point of providing packages to end users (that's the goal right? i mean the people making the packages are all happy compiling from cvs so...) if the end users are so confused by the multitude of incompatible debian kde 3.x packages. The situation as it stands is very nearly FUBAR. I mean we almost have every combination of possible packaging scheme with everyone going there own direction. I mean choice is good and all, but this is ridiculous. Look at what the end users have to deal with: ( ( ( unstable -- testing -- stable ) || ( gcc 2.95 -- gcc 3.2 ) || ( KDE 3.0.X -- KDE 3.1* ) ) && third party packages of everything else ) so that's 12 different incompatible packaging schemes with only one having a long term upgrade future. Add the third party packages into the mix and you have an end user nightmare! So, now that I've described the problem I'll try and offer a solution ;) Why don't we secure a common web space (surely kde or debian has some space for us) and package kde3.1beta2 (the latest release) with gcc 3.2 (the latest compiler) and target sid (the unstable branch where all KDE 3.X should go.) AFAIK, this is precisely what Calc et al are doing. Perhaps some transparency and better communication would be in order. I am glad Karolina has the time and talent to package KDE 3.1. It would appear that we are not suffering from a lack of volunteers on this, rather we are suffering from a lack of clear leadership and communication. So the clear steps would be: 1. Everyone agrees to the plan 2. An eager volunteer secures web/ftp space (maybe we already have it and I don't know) 3. The leader of kde packaging either delegates or sets up the kde3.1beta source on the space secured. 4. The leader of kde packaging coordinates the efforts of all packagers into packaging kde3.1beta2 with gcc3.2 for sid and when a new release is made we should focus on that. In this way the unstable would always remain just that: unstable Anyhow, that's my opinion :) Adam
