Re: Forwarded: RFC: New source packaging format
jim@jimpick.com (Jim Pick) wrote on 23.10.97 in <87zpo0z0o3.fsf@fleming.jimpick.com>:
> Please tell me where I am wrong.
>
> In my head, at least, I haven't found a single flaw in my proposal.
> Maybe there is a flaw, and the point just hasn't been driven home
> to me yet.
>
> Most of the opposition appears to be based on the fact that I have
> violated some aesthetic (ie."dpkg-source is for source, dpkg-deb
> is for binaries")
And when people tell you technical points where your proposal is flawed,
those are "knee-jerk reactions", "uninformed opinions", and "aesthetics"?
Something is very wrong here.
> > I would be quite happy to throw dpkg-source away if I thought its
> > problems were more than a few bugs and missing features. dpkg-source
> > is already second-generation source format for Debian, and (new) .deb
> > a second-generation binary package format. dpkg was rewritten at
> > least twice.
> >
> > I'm not unhappy to throw things away if I don't like the design or
> > implementation; fundamentally, though, I think the design questions
> > that drove me to design dpkg-source the way it is would lead me down
> > the same route again. The implementation quality is not ideal, and it
> > is lacking a few bells and whistles, but the structural design of the
> > programs is still reasonable IMO, and many of the proposed new
> > features were envisaged at time of the original design and will fit
> > well.
>
> Ok, I understand you don't want to get rid of dpkg-source. After all,
> it was a lot of work to design and build.
Either I can't read, or you just "understood" the exact opposite of what
Ian wrote.
> But it needs lots of work.
> Could you answer these questions on the future of dpkg-source for me:
>
> 1) How do you propose modifying dpkg-source for handling additions
> of binary files to Debian packages (without uuencoding them)?
I don't know about Ian, but I suspect a relatively simple way would be to
have dpkg-source read a list of binary files, and handle those
differently.
*Modified* binary files are a little harder, but there are several options
how to handle those - at worst, dpkg-source could uuencode those itself.
> 2) How do you propose modifying dpkg-source so that you can support
> sharing upstream source between packages (ie. checker)?
That depends on how much support you want. Being able to do it at all is
not a technical problem (see checker), but a policy problem; an
improvement might be source dependencies of some sort. I think we
ultimately want source dependencies, but I also think we don't understand
them sufficiently right now. (And I think your proposal demonstrates this
lack of understanding. See Bruce's comments.)
> 3) What if the upstream source comes in multiple files? How do you
> propose changing dpkg-source to use pristine-sources for that?
There's a quite obvious way to do that. Do we _want_ this, though?
There are two cases: original source that is just packed up in several
parts, and original source from completely different origins.
In the first case, it could well be argued that this is a case of "weird
source packaging", and we actually want to repack those sources anyway.
(This is debatable, of course.)
In the second case, this has some obvious problems. (For example, we now
have two different version numbers ...)
> 4) Can you describe an algorithm for an auto-bootstrap compilation
> mechanism in detail?
That's a completely unrelated problem.
> I've already demonstrated that my proposal can do all of these things.
Actually, I don't think you have demonstrated 4.
Besides, dpkg-source fulfills some other design criterions which your
proposal doesn't fulfill, and which, IMHO, are a lot more important.
You might want to read the discussion when the current source format was
invented. It was on -devel, but I unfortunately don't remember when.
It has all the arguments on why dpkg-source isn't built on top of dpkg,
for example; why using .tar.gz/.diff.gz/.dsc is the way to go, and so on.
And it did convince most people.
MfG Kai
Reply to: