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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-14-2010, 08:31 PM
Ryan Hill
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, 14 Aug 2010 19:35:56 +0200
Harald van Dijk <truedfx@gentoo.org> wrote:

> On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote:
> > > So you want me to force everyone to update the package just to respect
> > > the LDFLAGS.
> >
> > yes. IIRC it has been stated on this list before, that a change which
> > changes the resulting binary always needs to be done in a revbump.
>
> If that's true, that doesn't make sense. Take one extreme case: let's
> say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it.
> But the majority of people using gcc don't even turn on java support,
> those that do have a working libgcj already, and gcc can easily take
> hours to build. Should you revbump?
>
> There are always exceptions. Maybe you don't consider LDFLAGS support
> in general one of those exceptions, but clearly some others do. You
> can't just tell them "there are no exceptions" when there are, you need
> to explain why this isn't a valid reason to make an exception.
> My impression, too, is that few people care enough about LDFLAGS support
> to want to rebuild packages for it, so I would not have bumped either,
> but I'm willing to be convinced I'm wrong.

I think it's up to the discretion of the maintainer in this case. Of course,
when you're not the maintainer, err on the side of caution.

(i wouldn't do a revbump for LDFLAGS on my own packages. CFLAGS, yes.)


--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgets to keep us from losing our minds
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 08-14-2010, 08:46 PM
Ryan Hill
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, 14 Aug 2010 17:00:38 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:

> > you don't need to subscribe, there's usually an AUTHORS file with emails you
> > can use...
> As I said, I thought that maintainers was responsible to do it since they
> follow all the bug progress after all. So according to you I should do all the
> work. Tempting

When you take on the task of fixing a bug in a package you don't maintain,
you are responsible for the whole task, not just the part you want to do.
You essentially become the maintainer for that change. So just do what you
would do if it really was your package.

And really I don't care if you upstream the patch or not, but when the
maintainer politely asks you to do so the correct response is "okay", not "do
it yourself".


--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgets to keep us from losing our minds
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 08-14-2010, 08:55 PM
Markos Chandras
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, Aug 14, 2010 at 02:46:21PM -0600, Ryan Hill wrote:
> On Sat, 14 Aug 2010 17:00:38 +0300
> Markos Chandras <hwoarang@gentoo.org> wrote:
>
> > > you don't need to subscribe, there's usually an AUTHORS file with emails you
> > > can use...
> > As I said, I thought that maintainers was responsible to do it since they
> > follow all the bug progress after all. So according to you I should do all the
> > work. Tempting
>
> When you take on the task of fixing a bug in a package you don't maintain,
> you are responsible for the whole task, not just the part you want to do.
> You essentially become the maintainer for that change. So just do what you
> would do if it really was your package.
>
> And really I don't care if you upstream the patch or not, but when the
> maintainer politely asks you to do so the correct response is "okay", not "do
> it yourself".
>
>
> --
> fonts, gcc-porting, and it's all by design
> toolchain, wxwidgets to keep us from losing our minds
> @ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

You misunderstood me. I never said "do it yourself". I said that I didn't know
that I have to do it myself and that I will do it from now on

--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
 
Old 08-14-2010, 10:00 PM
Dale
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

Richard Freeman wrote:

On 08/14/2010 02:35 PM, Duncan wrote:

User perspective here...

For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently). The alternative is triggering a
several-

hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.


Interesting - I was looking at it in the opposite way.

Not having as-needed means that I /might/ have to rebuild that one
package unnecessarily at some point in the future - if it isn't
upgraded first for some other reason.


Rev-bumping the build means that I /will/ have to rebuild that one
package for certain - right now.


I think we can all at least agree that this is a gray area as far as
the INTENT of the (apparently unwritten) policy goes.


I would like to echo Markos's comment that having policies written
down, if only to point stubborn maintainers to them, would be
helpful. The other reason to have them written is so that they go
through some kind of review, and there is some way of challenging them
if they no longer make sense.


In any case, I think we're making a pretty big deal about a pretty
small issue - we can probably all afford to think about this a little
more and move on...


Rich





I'm with Duncan as well. I update pretty regular, usually daily, just
because I want to update a few packages at a time. If I do a truly HUGE
update, what is it that broke what? If I do 3 to 10 packages and
something breaks, I can go look at those 3 to 10 packages for either a
version mismatch or just a plain old broken package. If I have to
update everything at once, where does one even start to look? I have
almost a thousand packages here and I would hate to have to go look for
a needle in a haystack. That's a large haystack to go looking in.


I might also mention that I see rebuilds from time to time where it
looks like nothing has changed. I always let them rebuild anyway
because I know there is something different under the hood that I don't
see. Open Office is one that I dread tho. lol Even tho it would mean
a gradual system rebuild, I'd say that I'm for it. As they get changed,
bump them up a notch and let them get rebuilt.


Back to my hole now.

Dale

:-) :-)
 
Old 08-15-2010, 08:13 AM
Thomas Sachau
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

Am 14.08.2010 19:35, schrieb Harald van Dijk:
> On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote:
>>> So you want me to force everyone to update the package just to respect
>>> the LDFLAGS.
>>
>> yes. IIRC it has been stated on this list before, that a change which
>> changes the resulting binary always needs to be done in a revbump.
>
> If that's true, that doesn't make sense. Take one extreme case: let's
> say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it.
> But the majority of people using gcc don't even turn on java support,
> those that do have a working libgcj already, and gcc can easily take
> hours to build. Should you revbump?
>
> There are always exceptions. Maybe you don't consider LDFLAGS support
> in general one of those exceptions, but clearly some others do. You
> can't just tell them "there are no exceptions" when there are, you need
> to explain why this isn't a valid reason to make an exception.
> My impression, too, is that few people care enough about LDFLAGS support
> to want to rebuild packages for it, so I would not have bumped either,
> but I'm willing to be convinced I'm wrong.
>
>

This is a nice example, why we should not create fixed rules for everything, but allow common rules
with the usage of common sense. If we now create a rule, which says "Bump on every change, always
and forever", people will complain for big things like gcc, openoffice or kdelibs. Instead, we have
a general rule, which every developer should learn at least from his mentor to revbump on every
change for installed files, but also to use common sense. In the case of openoffice for example, it
does not get a new version or revision for some minor updates, since rebuilding openoffice does take
much time and resources. The same should apply for your example of LDFLAGS for gcc, so you can do it
without a revbump there or wait, until a version bump comes in and directly add it there.

So while general, non-fixed rules may result in some discussions, they also allow adjustments in a
case by case decision, a fixed "Always revbump" rule creates issues at least for corner cases, in
this case packages with very long compile times.

--
Thomas Sachau

Gentoo Linux Developer
 
Old 08-16-2010, 11:31 AM
Peter Volkov
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

В Сбт, 14/08/2010 в 20:06 +0300, Markos Chandras пишет:
> On Sat, Aug 14, 2010 at 06:26:36PM +0200, Thilo Bangert wrote:
> > > So you want me to force everyone to update the package just to respect
> > > the LDFLAGS.
> >
> > yes. IIRC it has been stated on this list before, that a change which
> > changes the resulting binary always needs to be done in a revbump.
> List? Really? I use devmanual for ebuild development not list archives.

Heh, devmanual is second source of information and first is good old
official documentation. Take a look at our "Ebuild policy":

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

Now let me read it:


"Versioning and revision bumps"

"Package revision numbers should be incremented by Gentoo Linux
developers when the ebuild has changed to the point where users would
want to upgrade."

This general and a unclear sentence. Below it is explained quite well:

"Typically, this is the case when fixes are made to an ebuild that
affect the resultant installed files, but the ebuild uses the same
source tarball as the previous release."

For this this clear: if installed files changed do bump revision. And to
make this more clear later text discusses cases when no revbump
required:

"If you make an internal, stylistic change to the ebuild that does not
change any of the installed files, then there is no need to bump the
revision number. Likewise, if you fix a compilation problem in the
ebuild that was affecting some users, there is no need to bump the
revision number, since those for whom it worked perfectly would see no
benefit in installing a new revision, and those who experienced the
problem do not have the package installed (since compilation failed) and
thus have no need for the new revision number to force an upgrade."

Clear, right? And some exceptions, people mentioned in this tread:

"A revision bump is also not necessary if a minority of users will be
affected and the package has a nontrivial average compilation time; use
your best judgement in these circumstances."


Yes, we need to merge two piecies of information. But at the moment
we'll have to use both and in case devmanual has something unclear try
to look at other documentation. So, please, do revbumps for all changes
that affect installed files. ~arch is _supposed_ to be fast moving
target and for ~arch it's ok to rebuild package just for small fix. In
case users want something more stable that should use stable...

--
Peter.
 

Thread Tools




All times are GMT. The time now is 08:36 PM.

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