[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] How to write .mk for libraries that have no s
Re: [Mingw-cross-env-list] How to write .mk for libraries that have no source releases?
Wed, 24 Nov 2010 14:07:00 +0100
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20101026 SUSE/3.1.6 Thunderbird/3.1.6
I'd like to write a .mk for a library which is only git available (
How can I write $(PKG)_URL variable and $(PKG)_UPDATE section?
That's a good question that hasn't really come up yet. Since there
really is no package tarball, there should some kind of null $(PKG)_URL,
maybe pointing to /dev/null.
I strongly disagree with this, see below for explainations.
I disagree with my idea too, at least in its pure form. As you pointed
out later, the entire commit history of a package makes the patch file
much too big.
We'll have to find a proper solution to this.
One helpful detail is that the Git web interface allows for
downloading a certain version as tarball. See below for my
thoughts about using hashes as version numbers.
I agree it makes sense to use generated tarballs, assuming a good
solution to the hash problem.
One thing you might want to consider is whether each new commit in the
git repo should necessarily be seen as an "upgrade". Depending on how
you look at this, it might make sense to use a well-tested generated
tarball from the git service as a sort of baseline "release". An option
would be to put later less well-tested commits in a patch file, so they
could easily be undone in case of trouble. It partly depends on whether
the mingw-cross-env packager wants to play the role of release manager
for the package in question.