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

[Alberto Luaces]

"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