On Mon, 2 Jul 2007 15:49:38 +0530 "Kumar Appaiah" <akumar@ee.iitm.ac.in> wrote: > > 2. debian/changelog: experimental. I'm just checking - is this version > > to be uploaded to experimental or is this a hangover from the previous > > version? Change to unstable? > > Well, the situation is like this: the current stable is now "phased > out" and only bug fixes are made. 3.99 is the "development" version > which is going to become the next "in thing". Do you suggest taking it > to unstable? In that case, I can ignore the older stable one and track > only the current one. The decision is yours, but here's the background: 1. Packages in experimental are only built for other architectures "as time allows". I'll be uploading amd64 so if you and other users are on a different arch, it may take a while before the packages become available - even after the time in the NEW queue. 2. Unstable is full of development versions. If this version is likely to be regularly updated and Debian bugs will be easier to get fixed upstream. 3. Most users want to use unstable or testing - relatively few people choose to download packages from experimental. This translates into less people filing bugs so problems can go unnoticed for longer. 4. Packages in experimental are generally regarded as "likely to break other packages" - it is perfectly acceptable for a package in unstable to need regular bug fixes, regular updates and general activity. A package in unstable is not expected to break the rest of the system. 5. If you expect this version to be the version that most users would expect to be able to use, it should be in unstable. Let it migrate into testing and as Lenny approaches, decide whether to hold it back by filing a dummy RC bug if necessary. That way, it is available to the widest range of users. (It will also find it's way into Ubuntu.) > > Hmm. The pbuilder log still shows gcc-3.4 being installed. You appear > > to build depend on two different fortran packages: > > refblas3-dev Fortran 77 reference implementation > > lapack3-dev library of linear algebra routines 3 > > > > lapack3 Depends on libg2c0 (>= 1:3.4.4-5) which brings in gcc-3.4 > > again. lapack3 is also an old package (2005). > > I'll look into this. What is the alternative to lapack? I'm not sure there is one - lapack isn't the same kind of problem as atlas. This isn't a problem you can necessarily solve - more of an issue of which you need to be aware for the future. Perhaps try to contact the lapack maintainer and/or upstream and ask them whether lapack can be migrated from libg2c0 to libfortran2. I have no idea how difficult this may be but I would not expect it to be trivial. Also talk to your upstream about lapack and see if they are concerned about duplicate fortran libraries and stale code. > > I'm not sure it will - atlas is still shown as an alternative to > > rfblas3 in the dependency list of the libittp6 package. > > I saw that. So, should we leave things as they are, since atlas isn't > actually pulled in by default? I think so. > > This does, however, raise a different issue - is there some way I can > > test the package? > > I think I added a make check or make check-local to the 3.10 series. > That runs many test. See this: > http://buildd.debian.org/fetch.cgi?pkg=libitpp;ver=3.10.11-1;arch=ia64;stamp=1181111650 Those are the same tests, yes. > I actually _did_ this for the 3.10 series, but forgot to do it. *Sigh* > I guess I'm just learning how imperfect I am... No problem, just put it back in. > Thanks for the patient response. Since I am not on my sid machine > anymore today, I can't do anything till tomorrow morning. So, will > prepare things with the changes you mentioned. OK. >From the other email: > > Would you advise me to retain the lapack dependency and stay with > refblas, or add the gsl dependency? Also, I am not clear how to avoid > the lapack dependency, which forces me to depend on an old compiler. Does gsl replace lapack? If it does, then that solves the problem. At the moment, I don't think it is worth losing functionality to avoid lapack. The old compiler is only needed to provide a library for your build dependencies and whilst it is an issue, it isn't critical at this stage. If there is a replacement for lapack, by all means use it. If not, make a note in debian/README.Debian or similar about the issue and the ideas on how to solve it when it becomes more important. This allows other people to contribute (via the BTS) by providing the background information they will need. Feel free to link to the debian mentors archive for this thread or copy content from the thread into debian/README.Debian - the format should be similar to the debian changelog - see gpe-shield for an example: (You can use deb-gview to view the contents of the .deb in the archive without having to install the package - load the .deb and double click on any text file within the .deb to view it. Also works with manpages and images and can work within most browsers as a helper application. You can view a .deb for any architecture, not just your own.) $ sudo apt-get install deb-gview $ deb-gview http://ftp.uk.debian.org/debian/pool/main/g/gpe-shield/gpe-shield_0.9-1_amd64.deb Mentors archive: http://lists.debian.org/debian-mentors/2007/07/msg00000.html -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp77iVsoBxTY.pgp
Description: PGP signature