On 2007/10/26 01:27, Enache Adrian wrote: > > Here it is again, done as an OpenBSD port instead of as a "port" to the > > existing sources. It now loads at boot time if you follow the MESSAGE. > > There was, simply put, no need for you to do it.
Well, this is [email protected], the topic here is "Discussions about using and contributing to the 'ports' source tree." There is no need to do any of this, but some people are interested in making it simple to use all sorts of software on OpenBSD, and without their hard work there would be no ports or packages. > > I haven't tested it yet due to issues in qemu with "use kqemu" compile > > option. > > Test it thoroughly first, then care about the portage red-tape. What you see as red tape, others see as a method of quality control. To test things thoroughly, you usually need more than one person. > By 'drop it in qemu/patches and build the port', I was meaning the > following sequence of events: To have more than one person testing software, those other people need to be able to repeat the same installation. Otherwise it won't be clear whether a problem is because someone didn't successfully work out the correct meaning of your words, or whether it's a problem with the code, and so it won't be a valid test. If you have to track down just one problem like this, you probably wasted more time than it would have taken to work with the ports infrastructure in the first place. > $ cd /usr/ports/emulators/qemu > $ cat my_message[1] > patches/patch-kqemu i.e. a hand-produced patch, touching several files. > $ make In the ports tree, we can do something like this: $ cd /usr/ports/x/y $ make patch $ cd w-x/x/src $ cp file file.orig $ vi file ... $ cd - $ make update-patches This produces files in the patches directory, with a sensible filename so it's clear which patch file affects which source file, containing a unified diff with function names in the @@ lines (so when an update to the software causes the patch to fail, it's easier to hand-patch). And, it's less work than identifying the changed files and producing the patch yourself. Then, to send files to others for testing and comment, it's normal to send a tarball of the port directory for a new port, or a cvs diff against -current when changing an existing port. I don't know if you intended it, but your message came across as being quite abrasive. This often encourages people to ignore messages, which is not so good if you're looking for useful feedback on your work. When it's tested and working, then it's possible to deal with the real red-tape (like, whether it should be in a standard build or as a FLAVOR, etc)...
