Diverting from upstream

Mark Rosenstand mark at borkware.net
Fri Sep 8 10:59:35 UTC 2006

On Fri, 2006-09-08 at 12:25 +0200, Tilman Sauerbeck wrote:
> Mark Rosenstand [2006-09-08 11:53]:
> > On Fri, 2006-09-08 at 11:27 +0200, Tilman Sauerbeck wrote:
> > > Mark Rosenstand [2006-09-08 10:44]:
> > > 
> > > > One of my personal likings of CRUX is that it's easy to customize and
> > > > extend. Because it (used to?) keep as close to upstream as possible,
> > > > there tend to be fewer distribution-specific bugs.
> > > 
> > > We _still_ do. But it's probably related to the fact that we don't read
> > > all of the code of the software we're packaging and that we don't fix
> > > any and all bug (-> Debian ;D).
> > 
> > Totally fair, and that's also why I argue that keeping close to (if not
> > verbatim) upstream is the best bet for a project the size of CRUX.
> Sure, I think everyone agrees here.


> > Unfortunately I've had to fork some opt packages lately. For example, I
> > depend largely on GTK+ (GNOME desktop) so I just don't dare to patch it
> > for something I have no clue what does
> > (http://crux.nu/svnweb/CRUX/revision?rev=1701)
> You could had asked Matt, Johannes, or me about it (it was kinda a group
> effort to get that bug nailed :)
> The patch has been incorporated into GTK+ 2.10.2, btw. See the changelog
> for the bug ID (it's tiny, I'm too lazy to look it up right now).
> I think it's safe to assume that your GTK maintainer depends largely on
> GTK+/Gnome, too...
> I think applying that patch was the right thing to do...

If it was a bug fix, sure! The problem is that there were no description
of what it did, "added cptn's modified stock icon patch" doesn't tell
much. The fact that it fixed a bug, and preferably what bug it fixed as
well as it was applied upstream would have been really nice additions to
that commit message. (This is a general problem, I think. Take
http://crux.nu/svnweb/CRUX/revision/?rev=1678 for instance.)

> > I think that recently there have been a growing number of patches in
> > core and opt - are upstreams just getting insane? I get the feeling that
> > the heavy patching is also the primary reason we're stucked with years
> > old versions of things such as grub.
> I don't share the feeling that core and opt are getting more patches
> recently. I'm not saying it's not true, I just didn't notice it.

It could just be me being more sensitive to this :)

> Regarding grub - the version we're using isn't actively developed
> anymore AFAIK. Switching to the new development branch seems a bit risky
> to me. I'd rather stick to the old version here.

I'm all for sticking to the widely used 0.x branch, but 0.95 is 2.5
years old and 0.97 have been available for more than a year.

The patches applied to 0.95 include additions of essential features such
as support for splash images, and there's so many that they're
distributed in an out-of-tree tarball!

> > > > To avoid these kinds of distribution-specific problems, I'm kindly
> > > > asking packagers to think twice before deciding to divert from upstream
> > > > - perhaps even limiting it to "required for essential functioning of the
> > > > package" and basic CRUX integration (no nls, man-pages in /usr/man,
> > > > etc.) :)
> > > 
> > > Uh uh, I actually thought twice before doing that Openbox commit.
> > > I even contact upstream, ziomg! ;)
> > 
> > Ah, true, you said that. I shouldn't have used that as an example, it
> > was rather a case of "shit happens" :)
> > 
> > The autoconf 2.60 mandir patch was probably a better example.
> Agreed, that was a bit silly. We also already discussed that matter ;)
> I don't see how one case of "shit happens" and one case of sillyness
> shows a trend of messing up opt ;D

Those were just the ones on the top of my head, but I have to admit that
I don't understand what all the shadow patches are for. Some comments in
the patch headers or in the Pkgfile would be warmly welcomed - after all
there's a lot of tinkerers in the CRUX crowd (cruwd? OK, no more coffee
on my day off) :)

More information about the CRUX mailing list