FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 03-23-2011, 08:45 AM
Ljubomir Ljubojevic
 
Default Updates from today

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...

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.

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.

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.

Yury V. Zaytsev wrote:
> On Fri, 2011-03-11 at 03:55 -0600, an unknown sender wrote:
>
>> Now, upstream releases a new package ... what do you do? Lets import it
>> into our SCM. Hmmm ... it overwrites the spec file and removes my
>> changes ... that's OK, I can still see them from commit 1, so I will go
>> back and grab them from there and reapply them into the new spec file.
>> But now, that makes the versions complicated and bringing in the new
>> spec shows me what upstream changed, but it does not show me anything
>> more about my changes than the first one did. During the build process,
>> I need to add another patch and specfile change and make a commit. Now,
>> I have 4 changes to the spec file ... which ones are mine and which ones
>> are upstream? After about 3 or 4 cycles it is all muddled. However, if
>> I grab any version of the upstream package and the corresponding centos
>> version of the package and diff the SPEC and SOURCES directory of those
>> it tells me in an instant exactly what is different from upstream. So,
>> for the SPECs it is MUCH easier to get the info you want to know (what
>> did CentOS roll in on package x-y-z.1) by using SRPMS than by using SCM.
>
> Hi Johnny!
>
> I don't want to get actively involved in this debate, particularly
> because my competences are somehow limited, however I thought it could
> be valuable for you to know that Debian and its derivatives have exactly
> the same problem.
>
> To solve it, they authored a toolset that wraps around the package
> building facilities (pbuilder is the mock of Debian, debuild is
> equivalent to rpmbuild etc.) and different kinds of SCM.
>
> There are several concurrently used sets of tools, for each SCM of
> choice, most notably git-buildpackage, hg-buildpackage, svn-buildpackage
> etc. The point here is to solve exactly the problem that you are
> discussing.
>
> They automatically create tracking branches on top of upstream imports
> (upstream could be the original author of the program, or a packaged
> version of the program e.g. from Debian that is considered to be
> "upstream" by a derivative, i.e. Ubuntu) that let you re-base your older
> changes on top of newer upstream changes, tag the uploads you do to the
> archive, combine all patches in one pack of patches, concurrently work
> with several branches for different distributions (backports),
> auto-generate changelogs and much more. At the same time, the
> immutability of the original upstream tarballs is guaranteed by a tool
> called "pristine-tar" and validated by computing a hash.
>
> That is to say, that this problem has been solved rather efficiently for
> Debian and allows for a very enjoyable packaging workflow using your
> favorite tools to manage the history.
>
> It could be that there are similar efforts for RPM-based distributions,
> but I am not up to date with that. It's rather a proof of concept.
>
>> The SRPMS themselves are BETTER tracking devices than an SCM.
>
> Provided a right set of tools, they are definitively not, as are not
> "source debs". It could be that these tools do not exist for RPM based
> distributions and if indeed they don't, CentOS might not be the right
> project to develop them, but just thought I would mention that.
>
> To me this point is of an academic interest.
>

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-23-2011, 09:02 AM
"Yury V. Zaytsev"
 
Default Updates from today

Ljubomir,

On Wed, 2011-03-23 at 10:45 +0100, Ljubomir Ljubojevic wrote:
> Yury, you have missed the point, as many before you.

I appreciate your answer, but unfortunately you were too quick to assume
that I am the one that is missing the point here. I need no explanations
of what and how CentOS does, as I am to a certain extent familiar with
the goals and the process.

The tools I am relating to pertain especially to the production and
maintenance of rebuilds and derivatives (where only a fraction of
upstream packages is changed), and as Johnny was generally questioning
the usefulness of SCM in these particular scenarios I though I would
mention how other projects deal with similar problems.

This was an informational email primarily for Johnny, which I also
decided to share with the list, since I've seen it before that
developers involved in one particular flavor of distributions are often
not up to date with alternative approaches from other distributions.

I tried to make the informational nature of my post clear. Please be
more of an attentive reader in the future to keep this thread clean.

--
Sincerely yours,
Yury V. Zaytsev

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-23-2011, 11:46 AM
Nico Kadel-Garcia
 
Default Updates from today

On Wed, Mar 23, 2011 at 5:45 AM, Ljubomir Ljubojevic <office@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.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 11:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org