[CentOS-devel] Updates from today

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.