W liĆcie z czw, 05-02-2004, godz. 14:43, Adam Majer pisze: > On Thu, Feb 05, 2004 at 12:08:54PM -0500, Grzegorz B. Prokopski wrote: > > I also though about it before uploading, but I think it was the cleanest way > > to do it, mainly because: > > - if I wanted the test suite to be in SableVM package then it has to be > > compiled > > during the build (and for each build separately) as I cannot include binary > > .classes, > > It would be a Arch:all package so buildd wouldn't build it and it only > builds once.
I think you're mistaking things. Either SableVM source contains test suite which it uses, so the test suite has to be build *each time* SableVM package is built - with all the consequences of it, or SableVM can just Build-Depend on sablevm-test-suite package, which then will be built once, sanely, avoiding chicken-egg and other problems. Even if it was allowed practice - I don't want to include in *source* package any binaries buildable from source. > These two can be combined. That is have the orig.tar.gz for SableVM contains > > upstream/ > sablevm > jasmin > test > > Then one source can build all of these packages - it makes build-depends > simpler. All of these are downloaded from the SableVM website anyway. Sure. So I guess most of GNOME base could also be built from single source, as it's all available on one website? ;-) No, sorry, I highly dislike what you've prosposed above. SableVM is a JVM and Jasmin is Java Assembler. I fail to see the point of polluting SableVM Debian package source w/ some project-unrelated tool. And this still doesn't solve the problem that I'll be compiling jasmin each time the package is build, then each time compiling tests w/ Jasmin running on a JVM that is yet to be tested by these very tests. That's what Build-depends are for. > OR, > we can add a new Arch:all package. It makes sense to me either way, but > I think it might be "cleaner" if all of these Sable stuff got combined > in one big source especially since jasmin doesn't seems to be changing that > often (the upstream tar ball has most of the sources dated to 2001). "all Sable stuff?" So maybe I should also combine SableCC, Soot, Ashes, StarJ, and a couple of other Sable projects, into one source package? They all come from "Sable" source, they all are about Java... ;-)) (Sorry, couldn't resist) Adding a new resulting Arch:all package-does such move buy us anything? I still would have all the hedaches I want to avoid, /var/lib/dpkg/status would stil contin the entry for this package and apt-get update would still have to retrieve info about the resulting binary package. The ONLY (doubtful) gain is having one *source* package less. And all that, IMO, would be at the cost of clarity, sanity and maintainability of the overall solution. (citing one line from your other, private mail below) > Also, why not combine sablevm and sablevm-classlib source? For similar reasons. These are distinct packages. Distinct upstreams (99.5% of sablevm-classlib is GNU Classpath). Updated at different intervals (sablevm is updated much more often, and there's no point rebuilding native part of GNU Classpath on each SableVM upload). Note: SableVM is not Kaffe, which includes much more things than a JVM. SableVM Project focuses on the JVM. I really appreciate other things that you've pointed out in the other, private email, but these to which I answered above - I strongly dislike and oppose. I hope Daniel will forgive us polluting his mailbox :-) HTH Grzegorz B. Prokopski PS: Can we declare EOT? Or at least not involve Daniel in the possible furhter disucussion. I would like to hear whether *HE* has any questions or I can just reupload the package. Daniel? -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org