Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> I was flabbergasted last night when I saw that Jim had answered my
> 14-point `why-not' list point by point. That message was intended to
> terminate the discussion, not start one.
Sorry. Maybe it would have had more effect on me if I read it before
I had already implemented my proposal.
> I've read Jim's writings on this subject and he is completely wrong.
> I really have better things to do with my time than argue with him
> about this.
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")
> If anyone else thinks there is any merit to Jim's proposal then I
> suppose someone will have to deal with the technical details, but at
> the moment I get the impression he's on his own.
Same here. :-(
Maybe that will change after a few more days of schooling you guys.
> 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. 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)?
2) How do you propose modifying dpkg-source so that you can support
sharing upstream source between packages (ie. checker)?
3) What if the upstream source comes in multiple files? How do you
propose changing dpkg-source to use pristine-sources for that?
4) Can you describe an algorithm for an auto-bootstrap compilation
mechanism in detail?
I've already demonstrated that my proposal can do all of these things.
A few more days of feedback, and I will write it up properly.
> I don't need to download your code in order to be able to tell that
> the design principles on which it is based are fundamentally flawed.
Please tell me how. I'm sort of reluctant to scrap my proposal based
on this assertion.
> Alternatively, take it from me as the author of dpkg: dpkg and .deb
> files are almost completely wrong for source packages. There's
> nothing that a .deb file could do for a source package that couldn't
> be done better and more simply by a .tar.gz file. All the features in
> .deb files - including the dependency mechanisms - are closely tied to
> the semantics of runtime package installation and management.
Perhaps I should use rpm for my example instead? I am just arguing for
the use of a packaging system for the delivery of source code, and a
nice separation of the upstream source and debian-specific source
directories, and the build-time temp directories.
> What you're essentially trying to do is to use a screwdriver to drive
> in a nail. You can't make up your mind which end of the screwdriver
> you want to use - the point (dpkg), or the handle (dpkg-deb) - but
> both are completely unsuited.
I am approaching it from the premise that a .deb file is just an 'ar'
file with two tarballs inside - one for control info and one for
binaries. An upstream tarball is a binary. The Red Hat guys seemed
to have figured that out. And why not use the control file? It
seems to express the exact same info as a .dsc file. I though the
.deb file format was perfectly suited to delivering source.
Sorry for wasting your time.
Cheers,
- Jim
Attachment:
pgpOVytJTt6kn.pgp
Description: PGP signature