Ola, [Compiling against testing] > > The answer was no, because this would mean that libraries in unstable > > would never get tested before they are moved into testing. > * Packages is tested when they are in unstable. > * Packages can actually require some newer version of a library > that can not be automatically detected. This kind of things > is prevented today. Hrm, there are only a few cases where a new feature found in a library is grafted onto it with no header files changing, basically the only case I can think of is new plugins. If a new feature is mentioned in the header files, then obviously the compile will fail if someone tries to use it in a version where the feature is not yet present. This is a bug, since obviously the build dependencies were too loose and would have required a minimum version. As an additional bonus we get advance warning if a library claims to be ABI compatible but isn't -- programs compiled against the old ABI that still try to run with the newer version will fail (and they will fail while the new library is still in unstable). So in short, I think compiling packages against testing makes sense. The people running unstable to get your package some testing will most likely run the unstable version of the library as well, and the people running testing can test the main program as soon as it enters testing without installing the newest (broken) libs that would otherwise hold it off testing. > the current setup makes packages (including libraries) to be more > tested than before. Well yes they will be included faster becuase > they are not held because of problems on other packages in the > high rate as now. Newer libraries are still tested by almost as many people as before. The "almost" are the people who upgraded some libraries to unstable in order to have the newer features. So there is no problem at all. :-) Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
Attachment:
pgpUsMsIipUhh.pgp
Description: PGP signature