hi debian/rules is work in progress...
currently are 5 different families of checks/conditionals 1) to differentiate between MPlayer-in-Debian and MPlayer-with-mpdvdkit 2) " " " a build for Sarge and a build for Etch 3) " " " a source coming from a .tar.bz2 and from SVN (the SVN does not contain prebuilt html docs) 4) to build w/ or w/o optimization. 5) to compile with an external ffmpeg, (but it is commented out) I agree that those conditionales make debian/rules less readable; but it works. I am not currently willing to remove those checks.... for example, from time to time I did build a version of MPlayer as upstream ships, so I need checks (1). And so on. On Mon, Feb 05, 2007 at 10:21:11AM +0100, Fabian Greffrath wrote: > Thank you for your answer! > > > > As a preliminary step , I catalogized in debian/patches all > > patches I worked on; but currently those are just there > > for documentation purposes. > > Maybe you should differentiate between your own personal working-copies > and releases to Debian; for the sake of readability. it is in my TODO list ; I will do that when I will package 1.0~rc2 > How about the other issues I mentioned? > > - I guess it will save much work if you simply threw out mpdvdkit off > the tarball, rename it '+dfsg' or alike, and remove all the checks for > the origin of the source etc. I do not understand your point here > - Nevertheless the debian/rules file is still nearly unreadable. There > is no consistency in the style of commenting and indentation, lots of > empty line etc. if you want to improve indentation of comments, you are welcome... (I do not see that as really improving style - the file is not so readable because it is trying to do too many different things) > The same applies to the README.Debian* files (of course > this would also clean up a little bit, if you reduced to the > dfsg-source). I plan to have two README README.Debian for plain users (binary codecs, bugs reporting ...) README.Debian.devel for hacking (recompiling w/ optimization, debuggin) > Again I offer you help to clean up those files. Especially the README.* > files since they are expected to be read by the _users_. You may try... but style is a subjective opinion ... I prefer to be honest on this point: it may be that I do not like your style, and then I will not apply your patches. In other words: if you send me a beatifully looking but totally different debian/rules; and I do not understand it 100% and I am not 100% confident about it; then I will not replace my own. (The present one is messy but I know how it works.) Of course, I am not so strict on README.Debian . But do not forget that the version in the .deb is automatically generated. If you send me a patch, or a new version, it must be w.r.t. the version in the .dsc. Anyway do not waste too much time on it. a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous, http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
