Re: Core Extensions relocation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Core Extensions relocation
Дата
Msg-id CA+TgmoaVVkNZfmYH6ZHmX3UosW57BMCM0Nkq1_V-=FwDte1HkQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Core Extensions relocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Core Extensions relocation
Список pgsql-hackers
On Fri, Nov 18, 2011 at 9:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Why do you figure that, exactly?  The path of least resistance will
> be precisely to leave everything packaged as it is, in a single
> postgresql-contrib module.  I'm pretty likely to do that myself for
> Fedora and RHEL.  Subdividing/rearranging contrib makes the packager's
> life more complicated, *and* makes his users' lives more complicated,
> if only because things aren't where they were before.  It seems unlikely
> to happen, at least in the near term.

When we discussed this topic at the developer's meeting, I thought we
had general consensus that it would be a good idea to package a
limited number of important and stable debugging tools with the core
server, and I had the impression that you (Tom) thought this was a
reasonable thing to do.  If you don't, or if you did then but don't
now, then it seems to me that this conversation is dead in the water
for so long as you're the one packaging for Red Hat, and we should
just move on; you pretty much have unassailable personal veto power on
this issue.  But let's not pretend that the conversation is about what
packagers in general will do, because I don't think it is.  I think
it's about what you personally will do.

I think that if we move a few things into src/extension and set things
up such that they get installed even if you just do "make install"
rather than requiring "make install-world", packagers who don't have
any terribly strong personal agenda will decide that means they ought
to be shipped with the server.  However, if you're personally
committed to making sure that all of that stuff remains in
postgresql-contrib in Red Hat/Fedora, regardless of where we move it
to on our end, then that's where it's going to be, at least on all Red
Hat-derived systems, which is a big enough chunk of the world to
matter quite a lot.  Note that I'm not necessarily saying anything
about whether your reasons for such a decision might be good or bad;
I'm just pointing out that a good deal of our ability to make a change
in this area is within your personal control.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Core Extensions relocation
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: foreign key locks, 2nd attempt