On Mon, 26 Aug 2002 14:11:13 -0500 "guitarlynn" <[EMAIL PROTECTED]> wrote:
> > > +packages +glibc-2.0 > > > +glibc-2.1 > > > +glibc-none > > > +binaries > > > > > > I believe the seperation of glibc within packages will avoid > > > confusion between packages with the same package name > > > that actually differ in end use. > > > > If we use David's build system for our packages tree, isn't the glibc > > separation unnecessary? > > Has anyone evaluated David's build system yet? I'm sure he would > > appreciate some feedback. Is it a usable system for our packages > > tree? > > The tree looks great, however there is no source that I could find > located within the tree itself. It appeared able to pull the source > from a remote location from the tree, however I thought that we > found that doing that would be unacceptable under the GPL anyway > (possibly fine within the MIT licensing, I dunno). The GPL does not > support linking remote source as I believe we discovered and the > reasoning for getting the LEAF source tree up in the first place. > As I understand it, we simply need the source posted for compiled > binaries and linked from where the compiled binary is available for > download AND the source must be located locally. Does this really need to be done? If the source is unmodified, why would we create another internet residence for it (other than mirroring needs, in which case that's how we should handle it, although I don't think the LEAF project is in a disk space position to be mirroring upstream packages). I haven't seen anything in the GPL that says we need to duplicate unmodified source on our site. The last paragraph of section three seems to make linking to upstream sources okay. The distribution method for sources should match the distribution method of the binaries, but the purpose of the GPL is not to force multiple destinations to be available for downloading a single source package. It is to attempt to put legal constraints on the spirit of a community. Since it almost never behooves a company to become a true part of a community, the license tries to enforce the proper behavior from them. Companies (and some people, I should be fair) do not understand communities; they only understand free source code and shortened project timelines. Frankly, the true spirit of the GPL is being followed as long as we allow people to easily do exactly as we have done: download upstream sources, modify them to suit their needs (by patching) and compile them into machine-readable code for their platform. Doing these things will help us as developers sharing a common methodology, too. Also, if we make a modification to a source package (such as Bering has done with the scripts from freeswan) we need to have a proper way to make those modifications available so that people can use them (probably shell script mods are not a good example in this case, since technically they are available in the binary distribution). It should be easy for people to find and separate our modifications so that they can use some or all of them, in conjunction with their own. For instance, if someone wanted to use the freeswan modifications, but they had the regular route program, and they were masochists and had their own modification to remove the 300-line awk script in the "manual" script, they should be able to identify and modify our changes easily. They should be able to find a patch and exactly how to apply it, so that they can remove the parts of our patch that they don't need and find instructions and a build environment so that they can apply their own patch. Whew, that was pretty long winded. Essentially, we need to understand what the GPL means. It is not meant to be a burden on developers (which disk space is, in our circumstance, it seems) but to be a legal invocation of some concepts. We need to follow those concepts. It is sad when people come onto the list and make GPL developers afraid of ridicule or losing some privilege, when all they need to do is cover some accounting work. Yes, we should consider this a primary effort, but it is not trivial to do it right, people understand that. Our development has grown faster than we have kept up with the details, that's all. > > > The addition of a binary tree > > > will allow for compiled executables/utilities that are not part > > > of any core image or package that are available for LEAF. > > > > Please explain the need for a binary tree in src. Its purpose is not > > clear to me from your explanation above. Is it for source tarballs > > from other projects? > > There are several binaries that various people offer that are not part > of a LEAF package (su, telnet, etc....). It would be strange to stick > a non-packaged src in the package src, but another thought would > be to simply offer the binary src and not the entire LEAF package > since everything else in the packages are script and their own src > code. Thoughts? > > This would be source code that may not belong to any project. > I will need to include atleast one (that I have already compiled) > within the webconfig package I am playing with. Under normal circumstances, binaries have no place in a source tree. I could be convinced otherwise for images, tarballs of source (if we end up needed to do that) and maybe some other stuff. But otherwise, everything should be only in source or other plaintext form (xml for docs, etc.) Source control does little for binaries (at least CVS) > > > Any thoughts, as we need to have the src tree up and populated! > > > > Agreed. We have discussed this tree for over a year now, and little > > has come of it. We can't cooperate effectively on releases/branches > > or packages until we have a working src tree. > > Well, there can be many ramifications if the src tree is not up. These > concerns may include ridicule and loss of hosting, which I would rather > not see. SF has been exceptionally nice in the free hosting and services > offered. Again, we need to address it, but in doing so to look at it as a philosophical obligation rather than a legal one. Conclusion: Mr. Douthitt's system is the right one for LEAF. We should all follow it to the letter (and probably figure out how to cross-compile for other platforms while we are at it!) -- ------------------------------------------------------------------------ Chad Carr [EMAIL PROTECTED] ------------------------------------------------------------------------ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
