[EMAIL PROTECTED] wrote:
> On 2 May 2001, at 13:23, Ewald Wasscher wrote:
>
>> If I understand correctly how David does this it's not necessarily
>> obvious to someone other than David how a program is configured, and how
>> it is built, what files to use in the .lrp package, and what lrp
>> specific configs need to be added etc. So if someone decides to upgrade
>> a package to a new version, or juist wants to play with it he/she has to
>> find out again how to configure/build and package the program.
>
>
> This is true, more or less. However, the patches are readable, and
> are "unified" diffs - which I find readable anyway:
>
> common line 1
> common line 2
> - old line
> + new line
> common line 3
>
> I read these all the time, looking for changes.
Allright.
>
>> There is however another problem. If you want to build ash, you cannot
>> just simply do "make", as you need the bsd pmake program instead of gnu
>> make, and what's worse the version of pmake that comes with redhat and
>> friends is too old, it just doesn't work. So it will require some tricks
>> to be able to do a simple "make" to build ash. So IMHO it would be very
>> nice to have a standardized way of doing such tricks.That way everyone
>> should be able to understand what happens.
>
>
> ash is a bad example. Erik Andersen, the busybox maintainer, has a
> diff he applies which converts the pmake file to GNU make, among
> other things. As I've said, ash is a bad example - Erik's patches
> also add history as well.
OK, I'll take your word that ash is a bad example. It's nice that
Erik's patches convert the makefiles to gnu make, but I doubt that
history support is his work as history is already in the debian version
of ash; and afaik debian ash is THE port of ash to linux.
>
>> My main reason for making this proposal is that that way it should be
>> obvious to all of us what someone does to build and package a certain
>> app. First of all I just like that idea. Second you can check if I screw
>> up and I can admire all of the smart tricks someone else uses to build
>> that super-cool ultra-small size optimized glibc (and learn from it).
>> Third is that it has the potential of easier upgrading because the lrp
>> specific logic is kept seperate from the actual source. Aply the diff to
>> a new version of your program and if you're lucky you even won't have to
>> make any other changes to build and package the app.
>
>
> To me, all of this is in the unified diff file. Also, the lrp/
> directory should contain documentation that helps explain things, and
> the make file should be clear and contain comments.
I have to agree with that to a great extent. But many programs use a
"configure" script to configure the source tree to be built with certain
options. I really prefer to have a script in the diff that calls this
configure script to doing the configuration by hand and then producing a
diff that is used to do that when rebuilding a package..
>
>> The .orig.tar.gz is just a pristine source
>> tarball as distributed by the creators of the program. It is just
>> renamed to .orig.tar.gz The diff creates a subdirectory "debian" in the
>> source directory which contains all of the "trickery" I wrote about as
>> well as debian-specific config-files etc.
>
>
> I just create a subdirectory "lrp" in the source directory which
> contains all of the LRP "trickery" :-)
If I understand you correctly you put quite a bit of this trickery in
the Makefiles etc. of the program itself instead of in a script in this
subdir. I may be nitpicking but I find the latter approach "cleaner".
>> I suggest you download e.g. the ash source package from the debian
>> testing distribution. Unpack the tarball, apply the diff and try to
>> understand what happens in this "debian/rules" file in the patched
>> source dir.
>
>
> I'll have to look. ash is a bad example, I think, however.
>
If Andrew James doesn't take too much of your time you could skim
through the debian new-maintainers guide:
http://www.nl.debian.org/doc/maint-guide/
Ewald Wasscher
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
