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

Re: dpkg-source v2



On Tue, 2002-07-23 at 12:14, Joey Hess wrote:
> Colin Walters wrote:
> > Ok, let's take a step back for a second.  We're basically considering
> > introducing all this complexity because we want to be able to include a
> > debian/ directory in the upstream .orig.tar.gz.  
> > 
> > Is it really worth it? 
> 
> That's not the whole of my reason for wanting to give some control over
> what directories things unpack into, it was merely a launching off
> point. I think that without some such control the format is not really
> flexible enough. Without it some packages will require messes of
> symlinks be set up at build time to approximate the right directory
> structure. 

That is almost certainly true.  One example that jumps to mind is glibc
and linuxthreads; I think the unpacked linuxthreads source directory has
to be located in an addons/ directory or something like that in the
glibc source tree.

In that case though (as in most cases), I bet a single symlink
glibc-2.2.5/addons/linuxthreads-1.2.3 -> ../../../linuxthreads/
would do the trick.  You could just make that symlink in debian/rules.

> Making the debian tarball no longer be a special case offers
> the hope that other distributions may one day choose to use the same
> source format as well. 

Honestly, I just don't see that ever happening; the concept of
dpkg-source is just very specific to Debian.  It does stuff like parse
debian/control and debian/changelog.

> Piling on another special case of renaming the debian directory of the
> single .orig.tar.gz, iff there is only one .orig.tar.gz and it has such
> a directory doesn't excite me.

I agree, especially since when building the debianization diff we would
have to check for that directory, and rename it back to debian/ if it
exists.  Ick.

As I see it, we have two main choices:

1) Refactor the current implementation so that the filenames for
multi-source packages are as aj suggested; this avoids having to
hardcode a version anywhwere.  Multi-source packages would be unpacked
into subdirectories of the main unpacking directory.  We would still
keep the field Source-Style: multi in debian/control.
  Pros: relatively simple to understand and implement
  Cons: less flexibility for package maintainers, does not deal with
debian/ directory in upstream sources.

2) Add a file debian/source-control which specifies what sub-sources
exist, and how they should be unpacked.  This information would then be
encoded into the .dsc somehow.
  Pros: allows a great deal of flexibility for maintainers; would give a
way to work around the debian/ directory in the upstream source.
  Cons: More complicated to implement and to understand; requires adding
another file in debian/.

Does this seem right?


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: