Re: 8.2.23 packages?

On Sun, Apr 15, 2012 at 10:38, Christoph Berg <cb(at)df7cb(dot)de> wrote:
> Re: Magnus Hagander 2012-04-11 <CABUevEwTswYhj7CwtwVuT_cMoTB5-SVdwQ7JjjxjZTz9JJCe=Q(at)mail(dot)gmail(dot)com>
>> On Wed, Apr 11, 2012 at 08:52, Christoph Berg <cb(at)df7cb(dot)de> wrote:
>> Also - putting it in debian backports doesn't solve the Ubuntu
>> problem, does it? We currently have Martin's PPA for that, but
>> wouldn't it be Kind Of Neat (TM) to have a single solution for both
>> these scenarios?
>
> If it works for Debian backports, the same should probably work for
> the Ubuntu backports. (The problem there might be that they have
> different minimum versions, so while squeeze-backports might support
> 8.4-and-up, Ubuntu backports might only have 9.0-and-up.)

I wasn't aware backports.debian.org could be used for ubuntu :-) My
mistake in that case...

Also - neither one of those two is good enough of course, since
PostgreSQL 8.3 is still supported...

> Generally, yes, Ubuntu should be supported by whatever solution. I
> haven't created any Ubuntu distributions on pgapt.debian.net yet
> because there's already enough targets for now.

Right - it should be on the long term plan.

>> And for the record, I don't really like the concept of PPAs for this.
>> Not necessarily from a technical perspective, that works just fine.
>> But it's really annoying to have to explain to "enterprise" customers
>> that "yes, using a *personal* package archive is the proper way to get
>> your fully supported version".
>
> Nod. What we could do is to use PPAs to get the buildd part covered,
> and then pull packages from there to the "official" archive.

That we could certainly do: There are two steps to whatever we do -
one is the build, another is the distribution.

>> > Currently only me, but so far no one else has asked for access. (I
>> > didn't ask very hard, though.)
>>
>> Let's make sure the process is documented enough that it's easy to
>> scale, eh? ;) bus-factors are bad...
>
> I'll try to post some of my thoughts on the whole process here.

Maybe set up a wiki page? Or if there is want/need, I can set up a
project at redmine.postgresql.org (i know the RPM builders have their
own trac instance with tickets and such things, though not as much
documentation as one would want there either).

> Re: Peter Eisentraut 2012-04-14 <1334399550(dot)9019(dot)37(dot)camel(at)vanquo(dot)pezone(dot)net>
>> On ons, 2012-04-11 at 10:14 +0200, Magnus Hagander wrote:
>> > Could we in theory have our own buildds if we run this elsewhere? I
>> > know very little about buildds, so I wouldn't know. And it might be
>> > doable but just too much work - so please inform me :-)
>>
>> I don't think having autobuilders is really a priority for this.  As
>> long as we only support i386 and amd64, you might as well have someone
>> fill in the missing builds manually.  Having a full autobuilder
>> infrastructure is likely to be more work than that.
>
> From my POV, they are essential. There's so many targets to cover that
> so far most of the time I spent on the project was just building
> packages: For the server packages, that's 9.1/9.0/...,
> sid/squeeze/lenny, amd64/i386 (add Debian/Ubuntu later), for the
> modules packages that's sid/squeeze/lenny, amd64/i386 for every module
> included.

I think once you start adding modules it does become more of a
necessity, yes. For the main server, not as bad, but sure, it
certainly doesn't *hurt* there either.

>> With that in mind, I am somewhat doubtful about the integration with
>> backports.d.o.  It sounds nice in general, but the goals and constraints
>> of either project are not exactly aligned, so this will lead to
>> permanent conflict.
>
> Agreed. I still think that the support for PG versions on
> backports.d.o should become better, but the necessary changes will be
> the same as for pgapt.d.n.

Well, if we move the responsibility for maintaining it to
postgresql.org instead of backports.org (ignore the domain names at
this point, I'm talkinga bout the organisations), that will make it
easier in the long run to always adhere to the PostgreSQL support
policy - which covers more than the backports one. If we do have a
proper working and fully supported pg repository there, is there any
point to keep postgres in debian backports *at all*? Well, they can be
kept there of course, but is there ever any reason to recommend it?

>> I think taking the current reprepro-based architecture that Christoph
>> has already running is just fine (modulo some details, such as source
>> packages missing).  We just need to give it a permanent home, so people
>> can start using it.
>
> The missing source packages should be a thing of the past, I only did
> that for builds where the only difference to some other version was a
> new changelog entry and rebuilding the package.
>
> For the permanent home, I first like to get it more in shape.
> Imho, pgapt.debian.net is fine for the moment.

If it's not part of a firm, long-term plan, I'm afraid it isn't.
Larger customers need to *know* that things aren't going to change
again...

> Re: Magnus Hagander 2012-04-14 <CABUevEzxkg4gOhZaBqUqm4aEWxeE9+r=pYS_ces_=3eWvLvfGg(at)mail(dot)gmail(dot)com>
>> Having an automatic build environment is of course useful anyway. But
>> there are a lot of levels between a full infrastructure to do all of
>> it, and just a couple of scripts...
>
> The messy part is figuring out what to actually build. Building that
> is then just a script.
>
> I do have some semi-ready sql queries for that which I should either
> finish or explain to someone else what I think they should do.

Or both :-)

>> > With that in mind, I am somewhat doubtful about the integration with
>> > backports.d.o.  It sounds nice in general, but the goals and constraints
>> > of either project are not exactly aligned, so this will lead to
>> > permanent conflict.
>>
>> That's what I'm worried about as well. It got very clear to me with
>> the decision to drop 9.0 from backports (regardless of what happens
>> with that longterm) just shows that the whole backports project is not
>> designed to deal with what at least my goal for this is - which is
>> providing a stable platform across combinations of postgresql and
>> debian versions, making it possible to move incrementally and
>> independently between versions depending on external requirements, not
>> on OS requirements.
>
> 9.0 is still present on backports.debian.org. Though it will probably
> require a written policy somewhere to make it stay there.

Yes. It is. But there is a written statement today saying *it will go away*.

I know it's there, but it's not something anybody can rely on.

>> FWIW, if we want the repos themselves to run on the postgresql
>> infrastructure, we have resources to deploy that really quickly. The
>> yum repository was moved to the main infrastructure a few months ago.
>> However, we do not currently have resources to host *build nodes*.
>> Devrim has a build box that EDB donated that's used to build the RPMs
>> on a multitude of differnet virtual machines - it's quite possible
>> that this machine could be used to build debian stuff as well, since
>> it's just a set of xen (I think, could be kvm) virtual machines after
>> all...
>
> I should be able to arrange build nodes. Putting the repos on
> *.postgresql.org will be nice. But first let's get it really running.

Sure.

Just to be clear - what's actually needed to run that? A simple http
server is all, right? And then Some Way (TM) of getting the packages
onto it, like rsync or just scp?

(FWIW, the infrastructure currently runs on squeeze, so if debian
specifics are necessary, that can certainly be dealt with)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/