[Pkg-osg-devel] Project pkg-osg approved in Alioth

[Manuel A. Fernandez Montecelo]

On Monday 03 January 2011 21:57:05 Alberto Luaces wrote:
> Manuel, as you said, a very convenient way to take is to syncronize the
> source with every new debian package release. I think the natural "git
> way" would be to have versioning dependent on branches. That way, we can
> have experimental packages as well as security releases and the current
> release all in the same repository, only by switching branches. For
> example:
> | Branch         | Description                                           
> |           |
> |
> |----------------+-------------------------------------------------------
> |-----------|
> |
> | 2.4.0-1+lenny1 | Security release. Stems from the 2.4.0 tag in master
> | branch.     |
> |
> |----------------+-------------------------------------------------------
> |-----------|
> |
> | master         | 2.8.3 in sid/testing → 2.10 when released → ...       
> |           |
> |
> |----------------+-------------------------------------------------------
> |-----------|
> |
> | 2.9.9          | Experimental package that could be eventually merged
> | in "master" |

Despite I have experience with git, I'm not used to work with branches 
really -- and I'm no expert in any VCS.  So I am not aware of the day-to-day 
pros and cons.

Doing as you say and having 3 directories in the same branch make things 
works differently.  For example, if you want to change a basic thing 
affecting the 3 branches (quell a lintian warning for all versions, modify 
the control file, etc), you have to create one change and merge back and 
forth every branch, isn't it?  Having 3 directories instead, you would have 
to change 3 files and commit afterwads.

So I don't know which approach is best suited, or if this example is suited 
for the type of work that we'll be doing.  I am going to rely on the opinion 
of any of you who has more experience on this matter :)

(BTW, hopefully 2.4 will be very short lived and probably we'll never use 
it, maybe we don't need to create it at all).

(BTW again, I think that starting with 2.9 we should name the Debian package 
as "openscenegraph-MAJOR.MINOR1" (never including "MINOR2") for the source 
package, and the binary packages accordingly.  That way, packages depending 
on us wouldn't have problems since they would not depend on a generic 
"openscenegraph" package, and maybe we can do away with renaming binary 
packages due to SO changes.  Another option would be to always name the 
stable version as we do now, the devel versions with versions included in 
the name, but I cannot see advantages in doing that other than packages 
depending on us not having to change slightly their control files to depend 
on newer versions.  What do you think?).

> On a side note, maybe we should remove the OpenSceneGraph-2.8.3.zip file
> since the source will be already unpacked for every version. If we also
> get rid of the *orig.tar.gz one, can dpkg-builder regenerate it from the
> unpacked source as well without thinking it is not a third party
> package? The point is to automate the generation of those files in the
> less time consuming way, and avoiding possible errors.
> 
> That way, every changeset could be like
> 
> openscenegraph-x.y.z/
> →debian/
> →OpenSceneGraph

If I understood correctly, that's what you want:
http://www.debian.org/doc/debian-policy/ch-source.html (search for "get-
orig-source" within the page).

That way, we wouln't even need to import the .zip into our repository, only 
adjust the URL for the new version in that section of the "rules" file.

Is that what you asked?  I think that it's a good idea.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>