Re: RPM source files should be in CVS (was Re: psql -l)
От | Tom Lane |
---|---|
Тема | Re: RPM source files should be in CVS (was Re: psql -l) |
Дата | |
Msg-id | 5070.995663684@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: RPM source files should be in CVS (was Re: psql -l) (Lamar Owen <lamar.owen@wgcr.org>) |
Список | pgsql-general |
Lamar Owen <lamar.owen@wgcr.org> writes: > The biggest patching by far is > in the regression tests, which really are not designed to live outside the > source tree, but can be munged into shape fairly easily. Peter has already done good work in making it possible to build outside the source tree. ISTM that it would make logical sense to allow regression tests to be run outside the source tree as well, as long as the changes don't break the existing procedures. I have not looked at your patches in this area --- what do they need to do, exactly? > Being in CVS != being in the tarball(s), does it? Yes. When this was discussed last time, I think the conclusion was that packaging scripts should be in a different cvs module from the core sources. I think there are really two separate discussions going on here: one is whether we shouldn't try harder to roll some of the RPMset diffs back into the main sources, and the other is how we can make information about some of the popular packages more readily visible/available to the developers. Peter's stance on the latter seems to be "go look at the packagers' sites", which is defensible, but that's the current approach and I think it's not working. Leastwise I sure have no idea what's in the packages. If I can pull down one additional CVS module from hub.org and include that in my Postgres glimpse searches, I am actually likely to expend that much effort, and as a result will be a lot better informed. > Point being that bug reports that involve changes to the core code by > packages are happening, and confusion has resulted. A solution needs to be > found -- and, frankly, the packages aren't going away. Exactly. regards, tom lane
В списке pgsql-general по дате отправления: