canonical-x team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Fri, May 04, 2012 at 04:03:43PM +0300, Timo Aaltonen wrote:
> On 02.05.2012 23:01, Bryce Harrington wrote:
> > Introducing 'lts-pkg-rename', a tool for doing package renames for the
> > LTS point releases.  (Assuming we still use the rename strategy, rather
> > than pockets.)
> 
> Yeah, about that.. :)
>
> ps. this was not a criticism about the work you did, I just think we
> should revisit the decision(?) made last UDS, at least there's still
> time to think things over :)

Yes, I know there's still skepticism about the renaming strategy, and I
do think further discussion around that could have some value.  Who
knows, maybe you can convince everyone that pockets are the way to go.  

But until then, renaming was the consensus strategy at the last UDS
session.  I don't have a strong opinion myself (I'd merely be annoyed at
having to throw some scripts away).  But I do think we need to get
moving on this, *especially* if there's skepticism about it.  The sooner
we can render it to practice, the sooner we'll know if it can be made to
work, or is fatally flawed and we need to do something different.

So, even if you still feel this is a wrong approach (actually,
especially if you think it's the wrong approach), I still would like to
have your criticism on the scripts.


That said, some comments on the concerns you raised:

> I see huge issues ahead if we were to go the rename route:
> 
> - a partial backport would mean untested software combinations (with
> pockets it's minimal cost to include the full stack)

It seems to me that even with pockets, this is still going to be an
issue.

This is also one reason I think we need to get hopping on this.  We need
to buffer lots of time for lots of testing.

> - there will be some new protos/libs needed anyway, at least if the new
> xserver is backported

Yes.  The protos aren't a big deal; the dpkg-control script will insert
the renamed protos into the xserver's control file for it to build with,
and nothing outside X depends on the protos so we're good.  Same for any
other libs that are used *only* by X.

Libs which are used both by X and by stuff outside X will be trickier.

Looking through them, many are dependencies of xserver not for the
server itself but for some of the other optional binaries it provides.
Since they're optional, these don't worry me that much, the worst case
is just that those particular packages are uninstallable, it doesn't
sink the whole enterprise.  These need some deeper study but they don't
strike me as an intractible packaging problem.

Other libs probably are not going to change *that* much from release to
release.  Perhaps we can just ensure the xserver will work with the old
ones.  For libs that do change a lot, we just gotta make sure the .so
are versioned correctly.

> - to allow upgrades to the next LTS release we'd need to add
> Replaces & Breaks: '$foo-lts-backport-{quantal,rabid,squeamish,tardy}'
> to the package in T. Messy..

Messy maybe but also far down the track.  Also, one or two of those will
be obsolete before T comes around.

> - packages depend on libxfoo (>= bar), and since there's no way to add
> versioned provides to the libxfoo-lts-backport-* -package (debian policy
> 7.5) the renames just won't fly

Mind elaborating with some specifics?

> so even if we narrowed the set down to just the select few input/video
> drivers + libdrm, it'd look messy.

Messy, but as long as it works...

> And the backported kernel might need
> alsalib/pulseaudio backports, then all the above applies there too.

Yes, and this came up in the session as well, and also has work items
assigned to investigate.  Potentially they can also use these scripts.

> Too bad the session notes were really sketchy on _why_ using pockets
> was not discussed more, I wasn't there to discuss this and I believe
> Robert couldn't attend either. We really need a new session with all
> the stakeholders present (LP/archive/foundations too), be it at UDS or
> IRC/Mumble.

Well, I certainly don't want to close doors to discussing huge issues,
but the last UDS session was quite well attended by stakeholders and
pockets vs. renames was quite a lively debate, but it did come to a
definite consensus.  I seem to recall Robert being there but my UDS
memories are quite hazy; I do recall HWE matters kept you two from a lot
of the sessions so maybe you weren't.

I've gone ahead and re-proposed the blueprint for rediscussion at
UDS-Q so we can have those discussions, although to be honest I think
we'd be better off focusing more on the nuts and bolts than strategies.

I'm bringing Steve Langasek into the CC here in hopes you and he can
hash things out.

Bryce