[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: