Add build instructions

[slicer69]

Added new file (BUILD) with instructions for getting dependencies, configuring, and building the source code.

Added blurb to README with simplified build instructions.

[ArsenArsen]

Please amend the git message to adhere to the seven rules.

[bbonev]

I see no point in duplicating the text in the README, please drop the changes to README.md, we have to rewrite it anyways and then we will include a link (or reference) to BUILD. As noted by Arsen, please amend your commit messages, e.g. (to keep it simple it is OK to force push your branch instead of opening another PR, but both are OK, depending which one is easier for you):

Add build instructions

• document how to install all dependencies
• document how to get source via tarball or git
• document how to build eudev

[slicer69]

I've backed the changed out of the readme in my branch. And updated the commit message.

I hope this doesn't come across as being difficult or combative, but I want to share my "new person coming into this project" first impressions. I feel like we're going in circles here. Over the past two weeks I've been asked to do the following with the documentation:

Place build/install instructions in a file called BUILD, exclusively, don't call it INSTALL.
Put the instructions in the README file, dropping BUILD.
Put a summary of instructions in README with full instructions in BUILD.
Call the file with build/install instructions INSTALL, not BUILD.
Keep the instructions in BUILD, drop everything from README.

It seems each existing member of this project has a different view of how adding new documentation should be handled. And that's okay, there is bound to be some stylistic differences. But for a new person coming in, this is a bit confusing to get such a wide range of contradicting instructions. Getting this one page of documentation committed has been a two week process of minor edits, file renames, and reverting edits.

I feel this process could be helped by having someone designated or declared as being the mentor/leader/final-say person for new contributors. Maybe have someone listed in the CONTRIBUTING file as a contact point to act as the mentor/go-between?

Maybe this isn't the right place to have this conversation, but it seems most people in this group aren't on the debian-init-diversity mailing list where I got introduced to the project so I'm not sure how best to address concerns like this. But it's something I feel we could collectively work to improve for future commits and contributors.

[bbonev]

@slicer69 I am sorry for the confusion, most of which was caused, because I didn't discuss my points about this with the rest of the team. Thank you for your contribution! (yeah, that was tough)

As a summary:

• It is standard for install-able projects to have build+install instructions in INSTALL, here that is not the case, especially for an un-experienced user who may break their install (I am even considering to put BIG WARNINGS not to install)
• The purpose of the document is to help new people to start hacking on the code without prior knowledge of packaging and prior experience from where to find certain distribution's packaging source and how to deduce dependencies from that. We do not expect a user to download and install eudev (if they do, they are a superuser), hence there is no place of the instructions in the README.
• @blueness can you please help with a couple of lines how to build on Gentoo (the part with installing build deps)?
• @ArsenArsen can you please help with a couple of lines how to build on Alpine (the part with installing build deps)?
• @bbonev I will add ArchLinux and Fedora instructions shortly; I will also verify if the current ones are pertinent for Devuan/Ubuntu and amend them if necessary; I think that hacking the code on any Linux OS should be OK, but debugging and testing it is another story and soon that will become an important part

[ArsenArsen]

alpine instructions can be copied from the workflow I added recently

[slicer69]

@slicer69 I am sorry for the confusion, most of which was caused, because I didn't discuss my points about this with the rest of the team. Thank you for your contribution! (yeah, that was tough)

I really appreciate your positive response and how open you were about my feedback yesterday. I'm looking forward to poking through the eudev bug reports and trying to find additional ways I can be useful. Thanks very much for guiding and merging in this pull reuest.

[bbonev]

alpine instructions can be copied from the workflow I added recently

@ArsenArsen thanks for the pointer

I have directly pushed, we can fix what is not right afterwards