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 > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-02-2011, 10:48 PM
Jesse Keating
 
Default Notice of intent: patching glibc

On Sep 2, 2011, at 3:39 PM, Simo Sorce wrote:
> On Fri, 2011-09-02 at 22:28 +0200, Jakub Jelinek wrote:
>> On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
>>> Is there a specific reason glibc does this?
>>
>> Yes.
>>
>>> Can it not have a set of patches, one per change, as is usual practice?
>>
>> Fedora glibc sources are from git, and the bit diff is just generated
>> diff between the upstream snapshot and corresponding Fedora snapshot,
>> sans a few Fedora-only directories (which are packaged as extra tarball).
>
> Jakub I guess this would be some more work but why don't you just use
> git format-patch to get all the patches for the commits between the
> baseline and the top of the tree ?
>
> That would give you a set of discrete patches that mirror the commits
> you have in the git tree.
>
> Simo.


There are also ways to automate applying those patches in the spec file using git am and the %{patches} macro.

- jlk


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-02-2011, 10:50 PM
Jan Kratochvil
 
Default Notice of intent: patching glibc

On Fri, 02 Sep 2011 23:02:04 +0200, Adam Williamson wrote:
> about the 'fedora' branch of upstream glibc.

GDB uses a similar style for the merged patchsets in the Archer repository:
http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-archer.patch;hb=f16


> Given that this is an
> upstream branch anyway, it would seem simpler to make our Source0 a
> snapshot of the 'fedora' branch upstream, rather than starting with the
> upstream 'master' and then adding an ugly patch and a mystery tarball to
> turn upstream 'master' into the 'fedora' branch. I just don't see that
> doing it the second way adds anything but confusion...

The suggested way is made gcc:
-rw-r--r-- 1 jkratoch jkratoch 54082276 Sep 7 2010 fedora/gcc/f14/gcc-4.5.1-20100907.tar.bz2
-rw-r--r-- 1 jkratoch jkratoch 59121454 Jun 3 14:45 fedora/gcc/f15/gcc-4.6.0-20110603.tar.bz2

and I find it as difficult to manage updates over my 2Mbit ADSL (that is
downloading the whole tarball again and again, instead of downloading just
smaller differences); plus I was and sometimes I may be developing on GPRS.


Regards,
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-02-2011, 11:15 PM
Adam Williamson
 
Default Notice of intent: patching glibc

On Sat, 2011-09-03 at 00:50 +0200, Jan Kratochvil wrote:
> On Fri, 02 Sep 2011 23:02:04 +0200, Adam Williamson wrote:
> > about the 'fedora' branch of upstream glibc.
>
> GDB uses a similar style for the merged patchsets in the Archer repository:
> http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-archer.patch;hb=f16
>
>
> > Given that this is an
> > upstream branch anyway, it would seem simpler to make our Source0 a
> > snapshot of the 'fedora' branch upstream, rather than starting with the
> > upstream 'master' and then adding an ugly patch and a mystery tarball to
> > turn upstream 'master' into the 'fedora' branch. I just don't see that
> > doing it the second way adds anything but confusion...
>
> The suggested way is made gcc:
> -rw-r--r-- 1 jkratoch jkratoch 54082276 Sep 7 2010 fedora/gcc/f14/gcc-4.5.1-20100907.tar.bz2
> -rw-r--r-- 1 jkratoch jkratoch 59121454 Jun 3 14:45 fedora/gcc/f15/gcc-4.6.0-20110603.tar.bz2
>
> and I find it as difficult to manage updates over my 2Mbit ADSL (that is
> downloading the whole tarball again and again, instead of downloading just
> smaller differences); plus I was and sometimes I may be developing on GPRS.

I don't see why it would make any difference to download sizes. In fact,
they should get slightly smaller. When we bump glibc from master right
now, you have to download a new master tarball, plus new fedora tarball
and fedora patch. If we used the fedora branch as our upstream source,
you'd only have to download a new fedora branch tarball, which would be
slightly smaller than those three things combined.

I guess it'd cause a bigger download when Fedora changes are made but
master branch is not, but then that seems more a consequence of the
Fedora changes being in upstream git than anything else, which in itself
is somewhat odd.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 08:38 AM
"Richard W.M. Jones"
 
Default Notice of intent: patching glibc

On Fri, Sep 02, 2011 at 10:28:19PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
> > Is there a specific reason glibc does this?
>
> Yes.
>
> > Can it not have a set of patches, one per change, as is usual practice?
>
> Fedora glibc sources are from git, and the bit diff is just generated
> diff between the upstream snapshot and corresponding Fedora snapshot,
> sans a few Fedora-only directories (which are packaged as extra tarball).

That's not a reason.

Why not keep the Fedora branch in git and make patches from it:

https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/

This method is quite probably simpler than the one you're using now.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 09:59 AM
Matej Cepl
 
Default Notice of intent: patching glibc

Dne 3.9.2011 10:38, Richard W.M. Jones napsal(a):
> https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/
>
> This method is quite probably simpler than the one you're using now.

I am in the process of pushing our less interesting Xorg patches
upstream, and I had a great experience with quilt and managing patches
as patches. Not sure how it scales to the size glibc/gdb/guestfs patches
but it worked great for me.

(and of course, I wish Fedora left all the silly patch business and used
git only as $DEITY intended).

Matěj

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 11:43 AM
Jakub Jelinek
 
Default Notice of intent: patching glibc

On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote:
> > Fedora glibc sources are from git, and the bit diff is just generated
> > diff between the upstream snapshot and corresponding Fedora snapshot,
> > sans a few Fedora-only directories (which are packaged as extra tarball).
>
> That's not a reason.
>
> Why not keep the Fedora branch in git and make patches from it:
>
> https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/
>
> This method is quite probably simpler than the one you're using now.

glibc is doing it that way for many years, even when it was diffing upstream
CVS trunk vs. Fedora CVS branch, not sure if the Fedora changes from CVS era
would result in something reasonable with your tricks, but moreover what
glibc does now is fully scripted in the Makefiles and it would be extra work
to change it to something different. I'd say it is up to the Fedora glibc
maintainer to do it the way he prefers to (which is not me for a couple of
years now).

Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 05:31 PM
Adam Williamson
 
Default Notice of intent: patching glibc

On Sat, 2011-09-03 at 13:43 +0200, Jakub Jelinek wrote:
> On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote:
> > > Fedora glibc sources are from git, and the bit diff is just generated
> > > diff between the upstream snapshot and corresponding Fedora snapshot,
> > > sans a few Fedora-only directories (which are packaged as extra tarball).
> >
> > That's not a reason.
> >
> > Why not keep the Fedora branch in git and make patches from it:
> >
> > https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/
> >
> > This method is quite probably simpler than the one you're using now.
>
> glibc is doing it that way for many years, even when it was diffing upstream
> CVS trunk vs. Fedora CVS branch, not sure if the Fedora changes from CVS era
> would result in something reasonable with your tricks, but moreover what
> glibc does now is fully scripted in the Makefiles and it would be extra work
> to change it to something different. I'd say it is up to the Fedora glibc
> maintainer to do it the way he prefers to (which is not me for a couple of
> years now).

Well, not entirely. There are the packaging guidelines. I took a look,
and interestingly I can't find anything in there specific about how to
format patches: seems that 'one-patch-for-one-change' is just a
convention, albeit a very deeply-embedded one with most packagers.
However, there's this, on sources:

"There are several cases where upstream is not providing the source to
you in an upstream tarball. In these cases you must document how to
generate the tarball used in the rpm either through a spec file comment
or a script included as a separate SourceX:. "

There is no indication in the glibc spec of what the Fedora 'source' is
or where it comes from; anyone coming to the spec without prior
knowledge will be confused, as I was, as to the nature of this tarball.
Its nature and method of generation should be documented in the spec.
I'm not sure if the 'Makefiles' used to generate glibc.spec are part of
upstream glibc source - if so, a simple comment which says 'look at
foo/bar/Makefile in source0 for details' would be fine, if not, the
Makefile should probably be included as another Source, as suggested in
the guideline.

There's also this, for patches:

"All patches in Fedora spec files SHOULD have a comment above them about
their upstream status. Any time you create a patch, it is best practice
to file it in an upstream bug tracker, and include a link to that in the
comment above the patch."

This is a SHOULD not a MUST, but really, it's pretty basic - I'd say
it's more important in this case as the glibc patch is not a typical
one, and I think would leave most readers of the spec file confused. Its
nature and source really should be indicated by a comment. Too, there's
no indication of the 'upstream status' of the Fedora changes; once you
know they form a git branch, you could go upstream and look at the git
commit logs to discover the *nature* of the change, I suppose, but not
necessarily its *upstream status* - i.e. whether a change made in the
Fedora branch of git is Fedora specific, or is planned to be merged
into master, or what.

To look at things at a higher level: it's clearly the goal of the
guidelines that any interested party (with sufficient basic knowledge)
who comes along and checks a Fedora package out of git should be able to
_understand it_, and this includes finding out where all the stuff that
goes to make up the package actually comes from. glibc spec clearly
doesn't achieve this goal; the casual browser is left looking at a
gigantic patch and a mystery tarball and wondering where they came from
and what they do, as I was. This makes glibc not at all raptor-proof,
and not very amenable to outside review or improvements, which is rather
against the spirit of an open source, community project.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 06:56 PM
Roberto Ragusa
 
Default Notice of intent: patching glibc

On 09/03/2011 07:31 PM, Adam Williamson wrote:

> To look at things at a higher level: it's clearly the goal of the
> guidelines that any interested party (with sufficient basic knowledge)
> who comes along and checks a Fedora package out of git should be able to
> _understand it_, and this includes finding out where all the stuff that
> goes to make up the package actually comes from. glibc spec clearly
> doesn't achieve this goal; the casual browser is left looking at a
> gigantic patch and a mystery tarball and wondering where they came from
> and what they do, as I was. This makes glibc not at all raptor-proof,
> and not very amenable to outside review or improvements, which is rather
> against the spirit of an open source, community project.

And the mind goes to a recent case of "obfuscation by merging patches".

http://lwn.net/Articles/432012/

In that case RedHat acknowledged that a single giant patch is more
difficult to understand and it confirmed that this was considered a
feature (for commercial reasons); someone even started to debate
if that could be considered a GPL violation, on the "source in preferred
form" criteria.

Regards.

--
Roberto Ragusa mail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-06-2011, 11:09 PM
Adam Williamson
 
Default Notice of intent: patching glibc

On Sat, 2011-09-03 at 20:56 +0200, Roberto Ragusa wrote:
> On 09/03/2011 07:31 PM, Adam Williamson wrote:
>
> > To look at things at a higher level: it's clearly the goal of the
> > guidelines that any interested party (with sufficient basic knowledge)
> > who comes along and checks a Fedora package out of git should be able to
> > _understand it_, and this includes finding out where all the stuff that
> > goes to make up the package actually comes from. glibc spec clearly
> > doesn't achieve this goal; the casual browser is left looking at a
> > gigantic patch and a mystery tarball and wondering where they came from
> > and what they do, as I was. This makes glibc not at all raptor-proof,
> > and not very amenable to outside review or improvements, which is rather
> > against the spirit of an open source, community project.
>
> And the mind goes to a recent case of "obfuscation by merging patches".
>
> http://lwn.net/Articles/432012/
>
> In that case RedHat acknowledged that a single giant patch is more
> difficult to understand and it confirmed that this was considered a
> feature (for commercial reasons); someone even started to debate
> if that could be considered a GPL violation, on the "source in preferred
> form" criteria.

Well, yes, that parallel came up in my mind too, but really, the two
aren't particularly similar. I don't think there's any intent to
obfuscate in the case of the glibc spec, it's simply done the way that
seemed convenient to its maintainers at the time. Note the Fedora kernel
package is a normal source / split out patches set. I'm not sure that
whole kerfuffle is particularly relevant to Fedora.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-06-2011, 11:27 PM
Jef Spaleta
 
Default Notice of intent: patching glibc

On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson <awilliam@redhat.com> wrote:

Well, yes, that parallel came up in my mind too, but really, the two

aren't particularly similar. I don't think there's any intent to

obfuscate in the case of the glibc spec, it's simply done the way that

seemed convenient to its maintainers at the time. Note the Fedora kernel

package is a normal source / split out patches set. I'm not sure that

whole kerfuffle is particularly relevant to Fedora.


*Let me turn that on its head.

As more projects become git based over time, the preferred form for code development might actually be a bisectable git checkout and not broken out patchsets for some projects. I'm not sure the distribution and packaging model that we collectively understand now and which grew up in the cvs and svn dominated era fits really well in the git dominated era.* I think we are still groping around trying to figure out what the "preferred form" really is in the git dominated era. I'm not sure the broken out patchset will be it. It might soon be considered a legacy format in some situations. **


-jef

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 05:09 AM.

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