Re: best policies for third party Debian packaging and get-orig-source target
[Dropping debian-devel list]
Hi Faheem,
On Fri, Aug 09, 2013 at 03:00:25AM +0530, Faheem Mitha wrote:
>
> I've now put the project in question on Bitbucket at the following
> URL: https://bitbucket.org/faheem/corrmodel. This is still unfinished
> work, but the package should at least build.
Hmmm, I'm not a mercurial user and tried
hg clone https://bitbucket.org/faheem/corrmodel
but did not found any debian/ dir that way. In any case if you want
your package sponsored please if you have no very good reason to avoid
the alioth Git repository of Debian Med please use it. It has several
advantages over staying out of our team repository except just pleasing
my lasyness to learn something else. We are doing QA means and automatic
information gatherings in these repositories - so it is perfectly
reasonable .
> Any comments, and particularly those on packaging, are appreciated. I
> still need to figure out a suitable make-orig-source for creating an
> orig.tar.gz.
Well, that's somehow an upstream question we can not really help with.
As a rule of thumb try to avoid including things that could be generated
automatically.
> r-cran-scales is now in Debian, but r-cran-ggplot2 has not yet been
> updated. I see that r-cran-scales is not installable, because it
> depends on r-cran-munsell, which is not in Debian, at least not
> currently on my mirror for amd64.
This was answered by Charles and he had a good hint what to do
(approaching upstream). This would be really great help.
> >We can also work on preconditions for your package - you mentioned that
> >there are some R packages missing.
>
> Sure thing. Here is a list of R packages I am using. If a package is
> in Debian, the Debian package is in a second column. As you can see,
> five of these are not in Debian. I certainly think it would be a good
> idea to get these into Debian. If so, how should one proceed?
>
> yaml
> ggplot2 r-cran-ggplot2 (currently out of date in Debian)
> gridExtra
> gtable r-cran-gtable
> reshape2 r-cran-reshape2
> RPostgreSQL
Not sure about this - is this something else than postgresql-9.1-plr ?
> tikzDevice
> Hmisc r-cran-hmisc
> RJSONIO
I think we should proceed injecting these into Alioth repositories. You
find a plenty of examples and packaging R stuff is basically a matter of
copying from another package and changing names.
> >I think you mean the way you should create the private package? I'd
> >recommend applying the very same rules as for any other Debian package.
> >You are welcome to do the development in Debian Med Git / SVN at your
> >preference (as I said you now have commit permissions). The rules
> >are explained in our group policy[1].
>
> I use mercurial. Would you allow mercurial repositories in your
> system? If not, it would be difficult to sync between two version
> control systems, I think. At least, I have no experience in doing so.
I'm not really sure about how you can sync. The only thing what I'm
really sure about is that we do not want to mix in another Vcs in
addition to SVN and Git. Our team is open to pick from one of these but
IMHO the things you need to know are quite basic ones. In general you
do not really need to sync but just commit released versions which are
ready for packaging (except when using the new, not yet documented way
that is used by Charles). If you might decide for SVN you only need to
inject the debian/ dir which we really want to keep outside the upstream
tarball anyway. (This is what I forgot to wrote above: Please never
ever put the debian/ dir into your upstream release tarball.)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: