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.
> 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.
> 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.
> 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" :-)
> 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.
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
