Hiren Patel wrote: > Bob Proulx wrote: > > In this case of people trying to use rpm for closed sourced projects > > then usually the files will be installed by methods outside of rpm. > > So from your perspective, yes, they will appear "out of the blue". > > Of course this is frowned upon by free software advocates because it > > prevents the source from being distributed. But as far as producing a > > workable rpm file this is okay from a technical perspective. > > if you have to deviate from best practices, why not deviate only where > completely necessary? if something can be done with or without > deviating, why not choose not to deviate? Hiren I appreciated your question because it was thoughtful. What you are seeing is a collision of world views. For the free software advocate anything that does not provide the source in an easily accesable form is a violation of free software best practice. I agree completely. Not using rpm to build and not producing a src.rpm file is a violation of good free software best practice. However for the closed source proprietary camp providing source isn't going to happen. The best practice in the closed source camp is never making the source available. These two views, free software and closed source software, are diametrically opposed philosophical views that will never converge. As such they have different best practices and for close source using rpm this way is not violating their best practices even if it is violating those of a free software advocate. I don't like closed source proprietary software but the rpm license does not prevent using rpm to package it and manage the installation of it. In fact if it did then rpm itself could not be considered free software. As such rpm is available for use managing closed source proprietary software. The license allows it. There are no technical barriers to it. There are many advantages to using rpm to manage software installations. Use of rpm packages is requested of software vendors by their customers. It is only natural that closed source proprietary vendors will use rpm packages for their closed source software. Using rpm for closed source binary packages will annoy those who believe that any process other than the free software process is a bad deviation. It annoys me. But this cannot be restricted without also restricting rpm such that it is no longer free software. That would be far worse. > IMHO, most issues are philosophical, technicality must complement > philosophy. No need to be humble about that opinion because you are exactly correct about it being a philosophical issue. > > > The proper way, IMHO, is using the tar'ed binary tree as source > > > file. > > > > Of course doing it this way is fine. But it is not required. Among > > other things bundling a binary blob in like that allows a .src.rpm > > file to be produced that could rebuild the binary .rpm file. But > > because the source is not really source the .src.rpm file is not > > really useful. It could not be used to port the code from 32-bit to > > 64-bit for example. Therefore IMNHO in this type of case it does not > > really add anything over just having the files appear out of the blue. > > > > i disagree. What perspective do you assume when you disagree with the above? The admin consumer of the rpm when you install it? Or the developer builder of the rpm when you create it? It is always possible to tar up the binary files and use that as a source file. But if that is all that it is doing I don't see the utility of it. For example (a real example from my experience) let's say that the compressed tar file of the installed files is 5G. It takes a large amount of disk to store both the original files and the tar.gz and the src.rpm file plus the produced binary rpm file. Using an extra 10G to store the tar.gz and the src.rpm on top of the already required 10G for the original native files plus binary rpm is a lot of overhead. Also it can take a long time even on a fast system to move that much data around. Compressing and uncompressing that much data repeatedly is cpu intensive. Considering the fact that this does not include the source and that no one will ever rebuild from the src.rpm file it is not worth the effort to maintain it. It takes so much time and disk space that I eventually gave up fighting for it. This is just one example. > though i still think the source rpm should have the actual sources, to > make it useful obviously. i also think the build process should be done > via rpm, but if that is not possible, at least have the source rpm have > the actual source code tarball as SOURCE's, so that it is not an > unusable blob. It is always possible to build within the rpm. However it is often not practical to spend the effort to convert and clean up some horrid private-sector build mess to the point that it can be built in rpm. By not practical I mean because the boss won't pay for it. Most software projects that I have seen in the corporate world were grown in situ using ad-hoc development and need a lot of cleaning but don't get what they need. Some of the company processes that I have seen are absolutely terrible. Cleaning up a closed source proprietary project in the private sector can be a very problematic task. Remember that closed source projects in the private sector are rarely as high quality as publicly developed free software projects. They don't get the same level of review given to public projects. They don't have access to as much talent as public projects. Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
