[Git-dpm-user] I inform a developer about some of the problems with packaging.

Paul Elliott pelliott at blackpatchpanel.com
Fri Jun 6 22:31:34 UTC 2014 

On Sat, Feb 15, 2014 at 01:36:06PM +0100, Stanislas Marquis wrote:
> Hello Paul,
> 
> I am working on adaptation of pyswisseph 2.0 with your chosen debian setup.
> 
> I think the pkgconfig file found in libswe-dev is not correct, the include
> path leads to nowhere, it should be "/usr/include".

Thank You I will be making a patch for this.

 (I may use pkg-config
> to detect libswe installation at build time.) Or you choose to allow
> several versions of swisseph to be installed? In that case you should take
> care of the numbering of the libs too...
> 
> Sincerely yours,
> Stan
> 


When no sponsor showed up on debian for pyswisseph, I moved on to other
things.


My work is still on alioth.

I was thinking we could make a copy of that repository on github and 
begin collaborative work there. We could jointly work on the
packaging. The develpment would remain strictly your concern.


A word of warning, packaging is significantly different than
developing as an upstream, and the work of a packager.

a packager must make a sharp distinction between packaging
and development.


The developer is the upstream. In the case of pyswisseph this is
you.

It is possible to be both a developer and a packager, but such
a person must always be aware of which "hat" he is wearing.

a packager may not change the upstream, but only create "patches"
that the distro uses to make the package work in a distro.
a packager may not change the upstream. I can submit
patches to the upstream, to ask if he wants to include them in
the new release.

on the other hand the packager must insure that the package
meets all of debian copyright and build restrictions. It
is complex.

I use git-dpm to separate the work of the packager from the
work of the upstream. It is a complex program on top
of regular git.
http://git-dpm.alioth.debian.org/

A packager must know everything in Debian New Maintainers' Guide
https://www.debian.org/doc/manuals/maint-guide/
and more.

For example, the above tells how to package a program, but
how do you test it? Well new packages first go into "unstable"
and then into "testing". So if you want to test your program
before putting it in :-) you must run "unstable". But "unstable"
can be full of bugs! I have a "unstable" partition on my hard
disk that I use for packaging. However, due to an X11 bug, everything
displays weird using my current graphics card on "unstable". This
is a new card I just bought to get around the problem. I thought the
problem might be my obsolete built in graphics. It was not.
"unstable" works just barely good enough so I can see if the program is
working.

Some techniques common in the python world are not allowed in
debian, because they bypass debian copyright and build requirement
restrictions.

I am a beginning packager and need to get help from a DD debian
developer to get packages into Debian. My DD for libswe and maitreya is 
"Jaldhar H. Vyas" <jaldhar at debian.org>, but he does not do python.

In order to get pyswisseph into debian it will be necessary to find a DD
who is willing to work with us. Do you know any debian DD's who
work on python who are not hostile to astrology? Theoreticly debian
does not discriminate against "fields of interest", but there is
the practical problem of finding a DD.

But if we fail to get a DD we can take our package to opensuse
buildservice and have it privately built and published there.

To give you an idea of some of the things a packager must think
about, let us take your bug.

First when I verified the problem, I thought is this "really"
a problem with the packaging or the upstream.

In this case it is a problem with the upstream, because any user
of the package would want this fix even if they were not using
debian.

Some "fixes" are only relevant to debian and must be maintained
by the packager as a patch.

Sometimes the next release of the upstream will be a long time
from now so the problem must be fixed with a patch in the meantime.

Some "fixes" might be a good idea but impose considerably on the
upstream who must deal with many distros and development environments.

Some "fixes" are a debian hobby horse.

Sometimes you have a recalcitrant upstream that refuses to do 
things the right way.

In the case of your bug, I am the upstream, because I have forked
the people at astrodienst.
http://swissephauto.blackpatchpanel.com/

Not the astrology, just the tarball and the build system.

So in a sense, I am both the upstream and the packager,
but I do not change the astrology as a matter of policy.

The astrodienst tarball is perfectly legal all completely
gpled. Nevertheless, it is totally unacceptable for debian.
A .dfsg package is another way to deal with problems like
this if they are minor. These problems are not minor.
It contains  binaies. Unsourced, (in that tarball),
documentation. That documentation is sourced somewhere else. It
uses a totally obsolete build system. The source does not
keep old tarballs. The list goes on.

It is really not intended for distro development. I believe
it is intended to divert amateurs into the GPL so that libswe
will never have a propiatary competitor (it is dual licnesed.)

That is OK. I believe in the GPL and would not have it any other
way.

I created a fork that fixed these problems without changing
the astrology. Your bug is not an astrology bug. If your
problem were an astrolgy bug I would report it to the "real"
upstream and wait. By "real" I mean the upstrem's upstream.
In this case. Some forks consider themselves to be indpendant
projects. Swiss Ephemeris AutoTools does not consider itself
that way. It is a matter of interpretation.

So I will take your report and create a new tarball for
Swiss Ephemeris AutoTools. This I will do wearing my "developer"
hat.

Then I will put on my packager "hat" and take that tarball
and import into libswe.git using "git-dpm import-new-upstream".
In the general case there could be conflicts with previous patches
that I would have to resolve at this point. In this case, that will
not happen. I will update the changelog and the version number
with "dch -i" and import that into git.

Then I will check that I have not broken anything, and that
maitreya still builds and works.

I will then notify my DD about the new package release and the
need for an upload.

I have slowly learned this process over many months. I am still
learning.


> 
> 2014-01-21 22:23 GMT+01:00 Paul Elliott <pelliott at blackpatchpanel.com>:
> 
> >
> >
> > I failed to get into debian. I could not get a sponsor.
> > on Fri, 16 Aug 2013 18:58:54 +0200
> > the package request was converted from ITP to RFP
> > intent to package to request to package.
> >
> > It is impossible to know exactly why the package failed
> > to get a sponsor.
> >
> > Things to Do to get package into debian
> >
> > IMPORTANT Remove unsourced swisseph documentation from the tar ball.
> >
> > This doc is already available in debian in the package
> > libswe-doc where it is rebuilt from source.
> >
> > Unsourced binaries always force a package to become a .dsfg package.
> >
> >
> > Heavly document everything.
> >
> >
> > Get a packager with experience packaging DEBIAN python and political
> > "pull" with those known to sponsor python programs.
> >
> > Current packaging source is
> > Vcs-Git: git://git.debian.org/git/collab-maint/pyswisseph.git
> > Vcs-Browser: http://git.debian.org/?p=collab-maint/pyswisseph.git
> >
> > I would be happy to colaborate with experinced python debian packager.
> >
> >
> > sincere best wishes.
> >





> > > >
> > > > 2012/4/16 Paul Elliott <pelliott at blackpatchpanel.com>:
> > > > > Dear Colleague;
> > > > >
> > > > > I don't think this effort will be hampered by any anti-astrology
> > > > prejudice; I
> > > > > have already gotten maitreya into debian unstable.
> > > > >
> > > > > I am having to work with debian technicalities that apply to all
> > debian
> > > > > programs. Everything built must be rebuilt from source by the build
> > > > procedure.
> > > > > You must have a license for every file documented. No convenience
> > copies
> > > > of
> > > > > code. Many other small picky details.
> > > > >
> > > > > The system was designed by Virgos. :-)
> > > > >

-- 
Paul Elliott                               1(512)837-1096
pelliott at BlackPatchPanel.com               PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/git-dpm-user/attachments/20140606/6f6d035d/attachment.sig>

More information about the Git-dpm-user mailing list