On 25/05/15 05:04, Jaret Cantu wrote:
The common way to update the upstream source of a Debian package is:
1) Checkout the upstream branch.
2) Unpack a tarball of the desired version.
3) Commit all changes.
4) Tag the commit as "upstream/$VERSION".
5) pristine-tar commit /path/to/upstream/tarball.tgz
6) Checkout master/development branch.
7) Merge with the upstream
The only difference between the upstream branch and the
master/development branch should be the debian/ directory, so the
merge should go off without a hitch.
Thanks Jaret,
If I understood your steps correctly, that requires to have copies of
the upstream sources on the local development platform. One example is
your eudev project (https://git.devuan.org/jaretcantu/eudev). :) I am
sorry to use it as example, but I am sure you know about it much better
than anyone else.
This is actually one of the parts that I really cannot get my head
around that. If the source packages were already being properly
maintained on good development platforms, I don't see the point to have
their copy on the local development platform as that would be a waste of
disk space and double the development efforts in maintaining them. That
would only be necessary if the upstream sources were being provided in
tarballs, instead of for instance on git platform which their historical
changes are being recorded.
So in the case of the source packages that are located on public
development platform like github, what I thought needs to be done on for
instance Devuan's gitlab is to maintain only the build package script
like what I just did. :) In the packaging process in Devuan for
instance, the pristine-tar is being obtained from the upstream source
location and the *.debian.tar.xz (I am not sure the name of this) is
being obtained from its tag in Devuan's gitlab then both are being
uploaded into source repository together with its *.deb files after the
compilation and testing.
My understanding above might be wrong as I still need to learn a lot
about about all of these, both their technical and non-technical
aspects. So please do enlighten me.
Updating to a date instead of a release tag is also a bit unusual.
I assume that you are referring to the commit title of "Update for
gentoo eudev master branch up to commits on May 4, 2015". If so, yes I
was confused what to put in there as it is a master branch so no release
tag. I wanted to put the latest commit on the master branch but it looks
too long for a commit title, e.g.
https://github.com/gentoo/eudev/commit/8387ce96ffd04ce048368480a269cbf5166394db
or commit 8387ce96ffd04ce048368480a269cbf5166394db. So I decided to put
the date there instead. Do you or anybody have any suggestions to use
"more standardise" information?
The master branch of my gentoo-eudev gitlab's project is meant to be
always in line with the master branch of gentoo/eudev in github. I will
create branches and tags a long the line, but I need to learn how to
properly do that first. :)
~jaret
Cheers,
Anto
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
