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

Re: dealing with non-standard upstream packaging?


Thomas Viehmann wrote:

> > I was wondering if there is any info about best practice in the
> > situation where upstream source packaging doesn't use the standard
> > foo-0.1.2/ inside of foo-0.1.2.tar.gz scheme?
> Talk to the upstream packager and kindly ask about changing it.

This I have done. They say they will look at doing it for the version
after next.

> > I suppose repacking the tarball/etc before using dh_make is enough, but
> > is there a standard way to make this a bit more automated for new
> > upstream releases?
> Assuming that upstream has the stuff in some directory, I don't think that
> this is necessary nor that you should do that, as meddeling with orig.tart.gz
> is generally frowned upon. The dpkg tools (dpkg-source, dpkg-buildpackage,
> uupdate) are pretty smart about that. Not sure about dh_make, but that should
> easily be worked around.
> For new upstream releases, use uupdate and you'll never notice upstreams
> directory notation.

Ok, I guess I am missing what to read, the situation is this:
I wanted to package nsis (http://nsis.sf.net) for debian since I need it
for a project I wrote (chmdeco). The current upstream tarball is named
nsis205.tar.bz2 (version is 2.05) and it contains a directory named
NSIS, which contains the source etc. Referring to the maint-guide
package, I unpacked the tar.bz2 and ran dh_make, giving this:

The directory name must be <package>-<version> for dh_make to work!
I cannot understand the directory name or you have an invalid directory name!

I assume that I should not use dh_make do do the initial debianisation
in this case? In that case, what would be the best way to create the
orig.tar.gz? Or should I use the cdbs tarball.mk system?

> > Another, question: why do some orig.tar.gz files contain a tarball that
> > looks to be the upstream source, instead of being a copy of the upstream
> > source? gaim for example.
> Different philosophy of packaging. This is especially useful if the upstream
> source consists of several parts.

I note that this style of packaging is mentioned in the cdbs
documentation, but there is no mention of why to use it. Has this been
discussed somewhere before? Either way, I'll probably submit a patch
summarising that discussion and peoples comments in this thread.

Thanks for the info everyone.


Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: