On Wed, Mar 23, 2011 at 5:45 AM, Ljubomir Ljubojevic <office at plnet.rs> wrote: > Yury, you have missed the point, as many before you. > > CentOS has no interest in tracking SRPMS since the are **not** changing > them. All they want to do is to repack them and comply with rules of > repackaging them, which include de-branding them, etc... What you do not > have to change, you do not need to track... Yes, they are! They're changing the artwork and the trademarks and some of the documentation. They have to for redistribution. They're not modifying the *binary* portions, but it absolutely requires changes, or we wouldn't have ".centos" named RPM's and SRPM's, and the "centos-release" package would not exist. Keeping those changes well managed makes the work more replicable, and helps avoid precisely the "spurious dependency" issues that our helpful repackagers have reported elsewhere, and creeping library changes in the build environments. > If upstream would be nice/stupid enough to solve all issues with > properly solving dependencies, everybody could just run them through > recompiling and there would be no need for all of this hassle. And if our helpful packagers would publish their build environment layouts in an SCM, we could replicate them and help. I'd love to help, and have asked before for such access. The point earlier that diffs cannot be tracked if you do this is, I think, an understandable but misplaced concern. Here's how you do it. * Set up a canonical repository with the mirrored SRPM's from upstream. * Set permissions to "add" only. * Extract the contents of those into a repository with subdirectories for each package. * Set permissions to "add" only. * Set up a third repository. * Copy, or import, the contents of the second repository to the third. * Edit, or modify only in this third repository. * Branch as necessary. * Replicate as necessary for binary RPM's. This provides direct access to replicate materials for development, to compare differences, and to provide access for others through an SCM, to the changes and change history of the packages and source that *must* be modified for a rebuild. There are details that are sensitive to the particular source control system used. Subversion, for exemple, cannot gracefully handle comparisons between two distinct repositories, and would work better with subdirectories in one repository. Git would be better at allowing our contributors to make and record local changes without direct write access to the central repo, and is better in security terms. But those are details. The structure works, and I've used it to help companies commit changes against externally provided vendor source trees with source control. > Since upstream needs (more) time between their release and downstream > rebuilds, in order to make better profit in the mean time, they have > made problems harder for rebuilding crews. This is a conflated view of several recent issues. I think. Red Hat has a long and *VERY* good history of publishing such requirements. There have been what look like some accidental spurious dependencies, which they're resolving. (SuSE used to do that deliberately, don't know if they still do with their kernels.) There is the kernel tarball issue. That's understandable, but real. Red Hat is publishing their kernels as tarballs, rather than as the vanilla tarball with a list of ordered patches against it. This makes layering in, or out, specific patches much more awkward. Was Oracle being any better about this? Does anyone have actual pointers to their SRPM's? > For me, it's that simple. And I do not hold grudge on upstream, their > choice makes them profitable enough to be able to invest in development > of the product we use and pay not with our money but with our nerves. > Those who cherish their nerves more then money will buy upstreams > product, and the rest of our self will loose nerves and keep our money. > > Ljubomir.