[Pkg-octave-devel] QtOctave: removal of simplercs

[Thomas Weber]

On Sun, May 09, 2010 at 01:10:41AM -0500, Jordi Gutiérrez Hermoso wrote:
> On 8 May 2010 04:16, Thomas Weber <thomas.weber.mail at gmail.com> wrote:
> > I'm currently packaging the 0.9.1 release of QtOctave.
> 
> I pushed to git the work I have so far. I think I overwrote a fair
> amount of work, since I just blindly stamped over whatever you had
> there. 

I haven't pushed anything yet. However, you did delete quite some
changelog entries of packages already in the archive, so we most
definitely can't continue from there.

> It's a proposal towards moving all that extra crap in the
> source package to qtoctave-utils. Still got a few lintian errors, but
> overall seems in good shape.

Sorry Jordi, but this is the wrong approach. The problem is having 6
binaries for just one software; whether they are in one package or in
two is not relevant. 

And indeed, the generic names already cause a problem:
http://groups.google.com/group/qtoctave-english/browse_thread/thread/9e35648262e68a9a

Renaming is not the solution either; these are private binaries of
QtOctave and shouldn't reside in the normal $PATH (FHS has a place for
them, but I don't know it by heart and can't find it currently).

> Indeed, I see I just stupidly recreated at least some work because I
> started working from an old tarball. Argh. At any rate, some of my
> work can certainly be salvaged, and I guess I got my wish of packaging
> practice.

Jordi, please try to have smaller commits:
$ git show c6cce6b3a338f6ce6917d4596612a7e0e4af1186 | diffstat
 <snip>
 35 files changed, 503 insertions(+), 281 deletions(-)

That is a *lot* in just one patch. 

So, in order to get forward. We will not split the package now. I don't
see any sense in creating an additional binary package, that is useless
for other packages and is needed by QtOctave; we may as well ship it in the
normal package.

I appreciate your help, but there's no need to rush this. Whether
qtoctave is uploaded this weekend or sometimes during the week is really
not relevant - having a solution that doesn't generate more work in the
future is relevant.

	Thomas