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

[Manuel A. Fernandez Montecelo]

On Tuesday 04 January 2011 18:14:42 Alberto Luaces wrote:
> No, I meant a branch for every different version of the package that can
> coexist at the same time, that is, just one directory per branch.
> 
> Right now in the repository we have the history of the packages as they
> were uploaded to Debian. The history only goes forward, so the last
> security release is not available in the changelog, and it is lost for
> our purposes. Why not creating a new branch collecting that change?
> 
> In the same spirit, imagine we begin packaging experimental versions, in
> order to try new features. Some of them will be carried to unstable,
> some others don't. Isn't it more convenient to have a special branch for
> that purpose and later "cherry pick" the successful items to the master
> instead of having to revert things that didn't work in every unstable
> release?  In addition, it makes the main development independent of the
> experimental one.

OK, Fine for me.

> > (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?).
> 
> Maybe I'm not fully understanding you proposition. As I see it, if we
> dropped the minor version, even for us it would be more difficult to
> understand which upstream version we would be matching, as the only tip
> would be our debian version numbers, which would then represent a
> mixture between our packaging work and the upstream release work.

My proposal is not to do any black magic to hide versions, just name the 
source package "openscenegraph-2.9" (without the 3rd bit of the version 
number added, because that's unnecessary) instead of just "openscenegraph", 
and the binaries in a similar fashion.

Say, now "dpkg -l" says:

ii | openscenegraph | 2.8.3-6 | 3D scene graph, utilities and examples 
(binaries)

My proposal is that we would have two:

ii | openscenegraph-2.9 | 2.9.1-2 | 3D scene graph, utilities and examples 
(binaries), development version

ii | openscenegraph-2.10 | 2.10.2-3 | 3D scene graph, utilities and examples 
(binaries), stable version

Did I explain myself better now? :)


> For source compatibility, usually a newer version will do. I have seen
> for instance that flightgear requires any version newer than 2.8.0, so
> they won't have to touch their control file regarding OSG version in a
> long time, unless their upstream required them to do so, or because an
> OSG non backward-compatible change has arisen.

I think that it was from 1.x to 2.x that the Producer stuff changed, and 
some changes were needed in other places such as the event system.  So when 
OSG packages get updated in Debian repos, other packages depending on it 
(such as flighgear) might break.

Following the example, I was wondering (and that's why I proposed so) if it 
would be better for flightgear to depend on packages named "osg-2.8" 
(equivalent to depend on packages with generic name "osg" and versions >= 
something <= somethingelse).  In this way, we can even have two stable 
versions (2.8 and 2.10) coexisting for a few weeks or months in the future.  

But maybe it's not worth the effort, I don't know.  Or it's better to 
maintain the stable package named generically "osg", with no versions 
contained in the name, for some other reason.

> Now that I'm thinking about it, maybe we could write a rule to get the
> source from our repository, craft the orig.tar.gz file and continue the
> build...

We can do this either having the source in our repository, or if not 
supported, creating the .orig.tar.gz and putting it in Alioth's "files" 
area.  We only need to do this for every upstream release (every few 
months), so it's shouldn't be a ton of work.

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