1. Mandrake RPMS from the current Makefile as well as the Redhat RPMS,
create a tarball on the fly from the current directory. If you work from
a release (tag) directory, you would presumably get a release RPM. I'm
guessing this is the avenue taken by the Redhat package maintainer. I
don't see another avenue listed in the source tree.
However, I have never run a svn --version on any of the redhat packages.
Hold on. Checking. Ok.
Just ran the svn --version - my guess is that during release, the
maintainer takes the existing version, updates svn_version.h to the
release number and then compiles the branch as per normal. That would
make the most sense.
However, in reality, shouldn't we be able to generate release builds of
ALL versions, even historic one's? Shouldn't something coming out of a
tag/ directory BE a release??? Guess I'm a little foggy on that concept.
2. This system is currently broken for the Mandrake RPMS. Users that
have installed a 'release' binary cannot bootstrap to a Mandrake RPM
even if they want to. Hence my wondering how I can make the build system
available for the 0.29.0 tag.
3. There are no official release Mandrake RPMs available. So I would
like to make them available. Hence, my wondering how I should go about
making the Mandrake RPMs available.
4. The new Mandrake RPM build system needs to be in sync w/ the latest
source in order to work, for any given tag or branch.. In essence, I
need to know what the source for the branch looks like just before it's
frozen. If not, the build system is out of sync, and the RPMS will not
build.
The RPMS require me to patch a couple of files, used in the build
process - they are source files and not generated files, and have to do
with Mandrake's particular finickiness of locating files.
But I can't know what to patch until I know what to patch. As an
example, one of the python files recently had the member of one of it's
objects change name from .output to .filename - hence the patch broke
between 0.29.0 and the trunk - which I have dealt with. This is normal.
How do you want me to handle this kind of situation?
a. Post a list of dependencies?
b. Scan for changes?
c. Autoscan for changes?
d. Allow me to update the tags/ release just after the snapshot so the
build system matches? (This would seem to be the simplest - it would not
affect the source and would only need to happen once per release).
How will I know when to synchronize so that a tagged release will
compile correctly because the build system correctly matches it?
Thanks for your answers in advance. :)
Shamim Islam
BA BS
On Fri, 2003-09-19 at 14:55, kfogel@collab.net wrote:
> Hmmm. Why do you want this? Generally, a pkg maintainer always
> builds from a released tarball of Subversion anyway, I thought...?
>
> -K
>
> "Files" <files@poetryunlimited.com> writes:
> > I think I've got the Mandrake RPMs set up to compile the trunk. I can commit these.
> > But the trunk isn't stable as AFAIK. So for anyone to make use of them, they won't
> > become available until 0.30.0 is out. So I'm holding out for the moment. My tests
> > aren't complete yet.
> >
> > The stable rev is 0.29.0 in the tags directory which is rev 6982. Problem is the
> > stable rev doesn't compile a Mandrake RPM successfully. The changes that I made to
> > the Mandrake RPMS area can also successfully compile the 0.29.0 6982 rev.
> >
> > So should I make these available somehow? And if so where?
> >
> > And secondly, where can I put officially compiled versions of the Mandrake RPMs from
> > the 0.29.0 for anyone that wants a precompiled version?
> >
> > Thanks much!!! :)
> >
> > Later all.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 20 04:54:30 2003