Bug#228673: sablevm-test-suite_0.1_i386.changes REJECTED
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 <gadek@debian.org>
Debian GNU/Linux http://www.debian.org
SableVM - LGPLed JVM http://www.sablevm.org
Reply to: