Re: source packaging
On Sat, 9 Sep 1995, Richard Kettlewell wrote:
> I don't understand what you want to change the diff target to, in any
> case. The present diff target produce the diff between the original
> source and the Debianised source; this sounds to me exactly like what
> you are proposing to change it to.
>
> Clearly I'm missing something obvious.
Or perhaps I am. I reacted to jdassen's suggestion for a
debianizing script with an alternative (flawed, and later
refined in response to helpful criticism)
It seems to me as if we should get to a scheme where the
source-rebuilder (perhaps not the maintainer who prepared
the package but a user rebuilding it for his own purposes)
doesn't need to worry whether it's a new-style or old-style
package to rebuild it. He'd go through the same steps in
either case. That way, old-style and new-style packages
could gracefully coexist during a transition period.
Tools to support the new-style packages can be fielded as
an atomic change. Changing all the packages will take
longer. That suggests a need for some means for the tools
easily distinguish old-style from new-style packages. I was
thinking that different naming conventions for the file
containing the patches might be a simple way to do that.
> >2. Change the build target to use the ../.dpatches.gz file to
>
> Making assumptions about the location of the patch file may be
> probably a bad move?
Shorthand. take the "../" to mean the directory above the
directory into which the source package is unpacked.
> > debianize the sources and place a stamp-debian file. [...]
>
> This requires debian.rules to exist in the main source archive, of
> course. Now we've got a modified source package which has to be
> modified yet further to compile for Debian!
Yes. That's the flaw which the other helpful criticism pointed
out. It should have been obvious to me, but I was operating in
brainstorming mode (throw out ideas, and let discussion cull the
bad ones from the good), and went public with a half-baked scheme.
The group has worked well in this mode in the past, with back&forth
discussion converging quickly on a workable plan.
Reply to: