Quoting Matthias Klose <[EMAIL PROTECTED]>: > Donovan Baarda writes: > > Quoting Matthias Klose <[EMAIL PROTECTED]>: [...] > > I don't see how this was such a showstopper. Getting the > > dependancies right to ensure a clean transition would have been > > fairly easy. > > Then again, why do we use versioned packages for C libraries? If I > understand you right and translate your proposal for C libraries, then > we should package libdb3 as libdb and libdb-dev. Now we upgrade libdb > (v2) to the next version /v3). All packages that are broken by the new > version have to be fixed by recompiling. And all packages that cannot > be upgraded must be recompiled to use the now renamed libdb2 and > libdb2-dev. Am I missing something? I cannot call such a transition > "clean" and "fairly easy".
No. The modified scheme _did_ use versioned packages. It just added an unversioned wrapper package that established which one was the "default" for packages that didn't depend on a particular version. As I stated (perhaps not clearly) much earlier, there are three ways to handle multiple versions; 1) multiple versioned packages that conflict with each other 2) multiple versioned packages that coexist, using alternatives to select a "default". 3) multiple versioned packages that coexist, with an extra "wrapper" package that establishes the default. Neil's original scheme of versioned packages + an unversioned default had the flaws you are descibing, which is why I convinced him to go for 3). > Why is Tcl/Tk packaged as a versioned package? You can leave the old > package installed when a new version is uploaded. Every package can be > upgraded in a safe way. [...] But with just versioned packages, you either rely on all other Python programs to depend on a particular pythonX.Y, or you have them depend on "python" and have all versioned packages provide "python", using alternatives to select which one is the default. This introduces some tangled problems with incompatible versioned extension packages. Assume the following is installed; python1.5 (provides python) python2.1 (provides python, higest priority alternative) python1.5-eggs (provides python-eggs) spam (requires python, python-eggs) spam's dependancies are met but it is broken, because python2.1 is the default alternative and python2.1-eggs is not installed. This is why Perl chose not to use alternatives... what if spam happened to be dpkg? (I know, Python is not as important as Perl) The scheme proposed fixed all these, at the cost of having one extra unversioned wrapper package to establish and force which version is the default. > AFAICR the schema would package the newest version as python > (unversioned) and the old version as pythonX.Y (versioned). No, I convinced him that was a bad idea :-) > > The biggest hassle with transition would be all the packages that > > just depend on python and install themselves into > > /usr/lib/python1.5. Until all of these packages have been upgraded, > > the default python (whether provided by a python (1.5.2-xxx) wrapper > > package, a python1.5 package, or a high priority alternative) has to > > be 1.5. > > And you don't have the hassle when upgrading from 2.1 to the next > version? Not if you use the "modified" scheme Neil eventualy decided on. This required version dependant packages like spam (requires pythonX.Y) to put themselves in /var/lib/pythonX.Y/, but it also allowed version independant packages like spam (requires python) to put themselves into /var/lib/python/ which a script would link into all the /var/lib/pythonX.Y/ variants. > [Assuming you mean this as Neil's last post] > http://lists.debian.org/debian-python/2001/debian-python-200110/msg00028.html Yeah... I just had a look again and saw that he said he would be away untill the 17th... I guess he's going to catch up with this all in the next day or two. Have a look again at that message, taking careful note of the positions of the '-' and '_''s and you will see he is using versioned packages with a small unversioned wrapper for establishing the default... Note that he also advocates a transition plan of having python (1.5) establish python-1.5 as the default untill all the broken packages that have (requires python) and install into /usr/lib/python1.5/ are fixed. > Managing the python binary without an alternative is the some approach > as we do it with gcc. But this is not always understood (see #101731, > #107587, #112887, #115353). These all highlight the problems with using alternatives, particularly the last one. I've just had a look at what gcc does and it seems they are doing what I was advocating; gcc (2.95.x) (requires cpp, cpp-2.95, gcc-2.95) is a small (3.2k) wrapper package that establishes gcc-2.95 as the default. cpp does the same thing. So if you've followed the gcc example, we're probably agreeing with each other :-) I'll have a look at the packages when they come through. -- ABO: finger [EMAIL PROTECTED] for more information.
