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

[James Goppert]

Hi guys!

Thanks for inviting me to the team! Junior developer should be fine for now.
I thinks that's what I am on the debian games team as well. My main focus
right now is developing oooark/ ardupilotmega/ and qgroundcontrol. Currently
qgroundcontrol depends on osg 2.9.9 so as I told Manuel I used the existing
sid package and did an upgrade to 2.9.9. I didn't make the package perfect
but it at least works for me and is hosted here: hsl.dynalias.com/debian

I have read your past few posts about git and separate folders or branches.
I think it would make sense to have the different versions tied to
exp/dev/master or possibly create branches name 2.9.9-dev/master/exp etc. If
you use separate folders I think you lose the ability to use git merge to
update stuff.

-James

On Tue, Jan 4, 2011 at 12:14 PM, Alberto Luaces <aluaces at udc.es> wrote:

> "Manuel A. Fernandez Montecelo" writes:
>
> > 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:
>
> [...]
>
> >
> > 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.
>
> 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.
>
> [...]
>
> > (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.
>
> 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.
>
> >
> >> 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.
>
> Yes, it is, thanks :) From the manual I have seen that it adresses http
> and ftp. As you found in the past :) , sometimes upstream packaging in
> zip files is not as good as it should be (mixed CR/LFs and so on). It
> would be ideal if we could use instead their svn repository as the
> source.
>
> 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...
>
> Regards,
>
> Alberto
>
> _______________________________________________
> Pkg-osg-devel mailing list
> Pkg-osg-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-osg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-osg-devel/attachments/20110104/4ad8369b/attachment-0001.htm>