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

Re: RFS: jampal

Hash: SHA1

Hi Peter,

please reply with the debian-mentors list in CC (at least). This helps
other people to keep track. You can, but you don't need to address me
personally as I'm subscribed there as well.

On 15.05.2011 16:56, Peter Bennett wrote:
> Since I am the upstream developer I can make any necessary changes
> so I thought it would be easier to make a native package. Otherwise I
> have to
> start learning quilt and other things. Perhaps I am wring in my
> understanding.

You don't need to know (almost) anything about quilt. A native package
is still wrong, as those are native /to Debian/, that is where no
upstream does exist at all. All other packages have to be non native
(being in 3.0 format or not).

The only difference, as of your point of view is, you have to provide an
unmodified orig.tar.gz packaging one of your releases, the 3.0/quilt
format merges with a debian directory you provide along. Note the debian
directory is automatically stripped from the upstream tarball if it
exists. This is because it is discouraged to maintain the Debian
packaging directly at upstream's VCS (i.e. yours).

> Since i was building a native package this seemed the correct thing.

You would still not put any release history there which was never
released as a Debian package. Please compare with the dpkg [1] changelog
which is a (real) native package.

> There is one command that uses lame, it is not a major part of the
> I could take out lame and mention that restriction in the man page.

Fair enough. All I wanted to say is, you can't distribute your package
in Debian while you depend (or recommend) lame.

> Open Office is used by the CD cover printing command and I included
> some example spreadsheets for Open Office that allow for updating of
> tags by spreadsheet.

Sounds like a good example for recommends, indeed. Maybe you find some
lighter alternatives, but this is definitively not a must have.

> Ok. I mention 40,000 songs as an example, perhaps I have to be clearer.

Maybe not in particular clearer, but more general.

> The postinst script for update-menu I added because lintian complained
> it was needed,
> although my experience showed otherwise.

Oh, ok. As said I don't know about desktop applications. More important
is the #DEBHELPER# hook which is used as place holder for debhelper
commands which can add their own hooks there.

> Actually ptts is not being built. I should probably remove the source.
> It is a windows program that goes with the windows version of jampal.

Please do so. Note, if you don't want to drop Windows support for you
upstream as well, you may want to repack the source tarball for Debian
(learn about DFSG tarballs on [2]). This is required for Debian if you
target main as this has to be self-contained. That is, it must be able
to reproduce your source package entirely with packages available in
main already.

> Same may hold for other libraries/utilities you
>> bundle (§ 4,13 [6]).
> tagbkup is a utility command that is bundled with jampal and used for
> some of the jampal commands. Perhaps it should be packaged separately.

Yep. See my policy reference.

> Sound & Video is how Ubuntu sets up its menu structure. I actually
built this for
> Ubuntu but submitted here to see if it could get into Ubuntu through the
> Debian process.

Apparently not :)

[1] http://packages.debian.org/squeeze/dpkg

- -- 
with kind regards,
Arno Töll
GnuPG Key-ID: 0x9D80F36D
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: