Re: svn commit: rev 7223 - trunk/packages/rpm/mandrake-9.1

Ok. Maybe someone needs to explain this to me once and for all.

I was backlogging the changes made over the course of 6982-current.

Was I supposed to go back and fix all the log messages that didn't
contain enough information? OMG. You can't be serious.

Second. I followed what was in the HACKING file. It said nothing about
explaining anything except for individual files. Did I miss that too?

Third. I copied the example Sander gave me. And I paraphrased the copy
that Ben Sussman gave me.

Fourth. Mandrake 9.1 Bamboo is the stable rev I have right now. A whole
bunch of people think that the other directories should go away. So I've
been trying to get the 9.1 version stable, and trying to figure out a
way to consolidate the whole thing into one directory. Seeing as that's
what people were complaining about initially.

Where are all the critics when you need 'em BEFORE you make the change.

Ben!!!! Help!!!!!!!

On Sun, 2003-09-28 at 18:44, Philip Martin wrote:
>
> When the change is spread over several files then start with a brief
> (one sentence, perhaps two) overview of the change.
>
> "Update Madrake package build to add support for Java." or whatever
> this change did.

How about "IT FREAKING JUST DID NOT WORK UNTIL I FIXED IT. IT WAS
COMPLETELY BUSTED. I FIXED IT OUT OF THE GOODNESS OF MY HEART. IF YOU
WOULD LIKE IT BACK THE WAY IT WAS LET ME KNOW."

I apologize, but Ben NEVER asked me to put something on top.

>
> > * 46_mod_dav_svn.conf
>
> * packages/rpm/mandrake-9.1/46_mod_dav_svn.conf
>
> The HACKING guidelines say to use full path names, the other log
> messages use full path names, you should use full path names.

It does not say anything about full path names. It only says something
about path names when your changes are strewn about in all sorts of
places.

As for the details of the fop scripts - they are not obvious. It has
nothing to do with ignoring errors. I've already been over this one. I
copied Sander's suggestion. If you have issues with his suggestion, you
two put your heads together and come up with a consensus.

> I'm not really interested in Mandrake or Java, I tend to ignore the
> dev list emails about them. As far as I can tell you have added some
> sort of Java patch (fairly large) to the Madrake build. What does it
> do? Did you write it? Did someone else? I should be able to tell
> from the log message, just a single sentence summary will do.
>
> I must admit I don't understand why you need to make such extensive
> changes to the build system in order to build Mandrake packages.

There is a patch that's been floating around in this discussion. It
modifies the javahl directory in the subversion/bindings/java.

Since *I* don't own the patch, I simply added it so that at least a
Mandrake JAVAHL RPM could be built. I will be removing it as soon as the
patch is finalized.

As for the changes to the build system, explain to me:

* Why I would have to go digging through the entire build process to
make updates to names of RPMs and version numbers.

* Why I couldn't build at all in the first place.

* Why the documentation build process is not running and therefore does
not create Mandrake doc RPMS.

* Why the build process is so noisy especially during RPM compilation
that I can't even see where the error occurred.

* Why I can't have the correct dependencies built in for Mandrake
systems.

* Why I would have to create special files just to create a Mandrake RPM
when Mandrake itself defines very strict guidelines to almost to thep
point where you shouldn't have to have ANY special files. (I can take
any Mandrake SRPM and simply build the correct binary). It wouldn't even
do ANYTHING until you created these 'special files' after going to a
website to figure out what you should do. And then to find out that the
things that it says to define, Mandrake has a set of stricter guidelines
on what they should be.

* Why standard Mandrake build system would break just because a
redhat-8+ packaging system decides to litter your system with dot files.

* Why the FOP system assumes locations of programs and hardcodes them
into the xsl stylesheets as well as the Makrfiles.

* Why the subversion/bindings/java/javahl isn't included in the regular
make process.

* Why there are dependencies missing as revisions increase especially
for Mandrake based neon.

* Why Mandrake standard directories are not enforced in Mandrake RPMS.

* Why Mandrake RPM binaries (dev build) cannot be identified.

* Why the fop system can't have options passed to it.

* Why you can't build only documentation RPMS.

* Why it can't *just* work out of the box.

If you can answer all of these questions, you'll understand why I've
done what I've done.

I've created an RPM build process that can be run by anyone.

I've created an RPM build process that allows you to configure what you
want to happen at the command line intelligently, and your choices
propagate through. I've allowed you to filter out the noise, as well as
turn it back on. I've allowed you to specify where your java is, as well
as if you want the java bindings built, whether you want documentation,
or couldn't care less.

I've given sweat and blood to make this usable for just about anyone.

And all I get is more and more and more problems and more and more nits,
and more and more questions.

Maybe I should have just built it for myself and ignored everyone else.

At least I would have been happy. Stupid me decided he wanted to give
back to the community and hopefully build or help build the stock
Mandrake RPMs.

********************************************************************

Will someone at least for once tell me what the membership of the Log
Police is and who is in charge?

I can't keep changing things every time someone *else* thinks that the
HACKING file needs to be interpreted yet another way.

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