[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: packages/rpm/mandrake9.1 files WAS: why patch build-outputs.mk in svn-install.patch

From: Files <files_at_poetryunlimited.com>
Date: 2003-09-18 06:56:04 CEST

On Wed, 2003-09-17 at 14:13, Michael Ballbach wrote:
> On Wed, Sep 17, 2003 at 06:00:53PM +0000, Files wrote:
> > You are wanting me to take over ownership of only the mandrake rpms
> > correct?
>
> I am not _wanting_ you to do anything, if you're interested then I would
> be open to that, yes, assuming you have more time then I do and that you
> have the skills necessary.
>
> My overriding concern is that subversion has reasonable support for
> building mandrake RPMs until the point that one appears in cooker and is
> maintained by mandrake itself. If you are in a better position then I to
> make sure that happens then that's great.
>
> > How do we do something like that?
>
> Well, I'd sort of like to see your changes first. I re-read the email
> and got a little concerned when you mentioned bundling the .rpmrc and
> .rpmmacros files. Those are individual preference files and they have
> no place being bundled with any specific RPM specification.

This is untrue. I can compile ANY Mandrake Linux SRPM without first
creating a .rpmmacros file or a .rpmrc file. This is due to the fact
that the Mandrake Linux RPM how-to which advocates is summarily ignored
by Mandrake Linux SRPMS by using safe defaults.

.rpmmacros by itself is unnecssary, since subversion.spec can contain
the macro definitions. The truth is that when I give you a SRPM, you
should be able to compile the SRPM to an RPM without doing ANYTHING
except rpm --rebuild <file>.

Separating the .rpmmacros file only prevents this every single time.

Therefore, a simple set of %defines at the top of the subversion.spec
file is sufficient. And since this is yet another place for definitions,
I've moved the actual definitions into the Makefile and propagated them
through sed.

The Makefile automatically generates the build tree for housing the
unpackaged SRPM as needed.

Makefile now:
1. Creates the build tree
2. Does NOT auto-activate the mod_dav_svn et al - since those are
SUPPOSED to be handled by the 46_*.conf file using the configure switch.
3. Defaults to /usr/src/RPM for the root user's build tree, and
/tmp/$(USER)-rpm for regular users.
4. Uses /tmp/$(USER)-$(PACKAGE)-root for the Build Root as do most
Mandrake Linux Packages.
5. Allows the user to correctly specify the name of the neon package -
since the neon package has been offered as neon and not libneon0 on
tigris forever, this is configurable so that subversion_clients-svn no
longer generates a libneon0.
6. All names of rpms and their correct versions are propagated into the
subversion.spec file along with default values if a particular version
is not found - e.g. I can create a subversion rpm using db4.1 and it
will correctly require db4.1 or I can create one using db4.0 and it will
correctly require db4.0
7. Apache configuration data is correctly passed to subversion.spec
8. Man directory settings are passed correctly - this was failing
previously
9. Buildroot is set correctly in the call to make via DESTDIR which
previously was installing directly to the system root since it was not
specified and overwriting stuff willy nilly.
10. libexecdir= line was missing a backslash causing compilation
failures.
11. Added a patch to svn-apache.m4 to correctly house extraneous
non-apache-built modules to /usr/lib/apache2-extramodules - no patch of
build-outputs.mk is performed (mod_perl, mod_ssl, mod_php et al).
12. Added a patch to Makefile.in and to gen_make.py during RPM
compilation and building to decrease the white-noise - if there is a
failure, this can be bypassed by doing a regular compilation - a la the
new kernel-2.6-test5 messages (CC, LCC, LINK, MKDIR, SWIG, SWIGCC,
APACHECC). Watching and RPM compile w/ all that noise is not my idea of
a fun evening. configure is also called with --silent.
13. subversion.spec currently compiles by running autogen AFTER
patching, since auto-generated files should not be patched.
14. The spec file and all unpackaged sources, when complete are erased
via the --rmspec switch as well as a directive in the %clean section
15. If apache2 is not present during bootstrapping, Makefile quits
gracefully.
16. subversion.spec identifies all files used at the top
17. Contemplating removing the python patch since I can't seem to
discover what it is used for and since it seems to never be applied.
18. Made a change to 46_*conf to account for the changed housing of the
third-party apache module according to Mandrake Linux conventions of
/usr/lib/apache2-extramodules.

Secondly, .rpmrc contains build-arch translations. These translation are
defined by Mandrake Linux. They do not change. They are not preferences.
So putting them into a single file that is used in conjunction with all
the default rc files (/usr/lib/rpm/rpmrc:/etc/rpmrc:~/.rpmrc) as well as
the subversion version, subversion.rc automatically builds the package
correctly.

I have been testing this set of changes under Mandrake-9.1 Bamboo w/
partial upgrades to 9.2rc2..

I am attaching the updated files of the contents of the directory
packages/rpms/mandrake9.1.

I'm pretty sure I've covered everything. I'm pretty sure I know what's
going on. I double-checked it against my MaximumRPM as well. Hopefully
you concur.

Cuz I gotta tell ya - I hadn't been able to compile a Mandrake Linux
subversion RPM since I started using subversion. I kept having to
install the redhat versions that were precompiled. Ick.

I'm thinking the acid test for this whole slew would be to give you the
SRPM and see if you can compile it. It should compile on a vanilla
Mandarake Linux machine w/ no modifications.

> They generally need some minimal content to generate RPMs for mandrake.
> They can, however, have wildly different contents depending on the
> builder of the RPM. Those instructions are meant as a very basic
> introduction to the user that has never built RPMs before, and not the
> be-all and end-all of how you should have your rpm build environment set
> up.
>
> Whatever other changes you have, I'd still like to see.

As you wish. I'm still testing, but this should give you an idea of what
I'm doing. This is by no means final yet. Thanks.

I just know that I for one can't STAND having to CREATE a bunch of
files, just to bootstrap something that I want to just use. It should
*just work*.

Let me know what you think.....I won't pollute the dev mailing list with
an unsanctioned SRPM, but I can send you one if you like.

Shamim Islam
BA BS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Thu Sep 18 17:13:23 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.