>
> When I sat down to send out Uncle G.'s patches to the debian
> developers I realized that the patches really only apply to a moving
> target. What I mean, is that they will only apply to current snapshots
> (i.e. Jun 23's), but not to the older 6.5.1 release. By giving out these
> patches, and telling them to just go and get a snapshot, they might end up
> getting the snapshot on a day that pgsql is broken, or the patch will no
> longer apply. The best solution I can think of is just to take one of the
> snapshots (today's if it works, testing it now, otherwise last Fridays),
> and setting it aside along with the patches in a seperate 'linux_alpha'
> directory so packagers can have something "non-moving" to package for
> thier distributions. Is this a good idea, or does someone have a better
> one?
I would try applying to 6.5.1, make any hand tweeks needed, and generate
a patch from that for 6.5.1.
> Also, I found at least a temporary solution to the problem of
> alpha CPUs being detected as alphaev5, etc... and breaking the 'alpha'
> makefile conditionals. Just add 'CPU:alpha' to the linux_alpha template.
> Is there a reason that this would be a bad idea? I don't even really see
> the reason why config.guess wants to differeniate between different alpha
> CPUs in the first place?
Some optmizations are turned off in some Makefiles like
backend/utils/adt and backend/storage/ipc. Now that I think of it, you
can't send out patches for 6.5.1 because we don't have the alpha stuff
in there that was put in after 6.5.1. I think the current snapshot may
be safe for general use.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
