[debian-mysql] unversioned packaging

[Clint Byrum]

Excerpts from Nicholas Bamber's message of Mon Apr 23 13:30:35 -0700 2012:
> On 20/04/12 19:20, Clint Byrum wrote:
> >
> > Another thing to discuss which is only slightly related to the rules
> > file is to ask why we are doing minor-version source package names. I
> > understand that transitions, in the past, needed this. However, IMO
> > now we should just have a 'mysql' source package and use experimental
> > to prepare transitions when a new major release is available. I can't
> > imagine a time where we want to ship *two* major versions of mysql in
> > the same release of Debian.
> >
> 
> Do you mean the source package would no longer be versioned or all the 
> packages?
> 

I mean the source package.

I find it very strange that it has been

mysql-dfsg-5.0
mysql-dfsg-5.1
mysql-5.1
mysql-5.5

When it really should just have been

mysql

This makes things like packages.qa.debian.org work in a weird way,
and also bugs in Ubuntu are source-package oriented so often bugs end
up affecting 4 or 5 source packages which is confusing and cumbersome
for no benefit that I can perceive.

The binary packages are, I think, named and versioned appropriately and
should remain that way.

> Anyway I have thought  of various implications. Mainly we have a lot of 
> installation/upgrade (i.e. piuparts) issues. In the long run such a move 
> is likely to reduce such issues but in the short   term increase them - 
> and we have not even begun to get on top of them.
> 
> Next maintaining a version in unstable and a version in experimental
> is a lot easier when you are using git. I would not mind moving to a 
> full   copy of the upstream code like other projects do as that would 
> make git integration   easier. On the other hand there are differing 
> opinions on how to use git and I suspect that the resulting arguments 
> become almost religious. If there  were disagreements I would retain the 
> current sparse layout. A plan might look like this:
> 


+1 for getting off svn. My git skills are terrible, so I prefer bzr,
but I understand that its position in mindshare is declining, so I would
be happy to learn how to use git-buildpackage finally. :)

As far as with code or without, I don't care either way on that either.
With code means patches are easier to keep refreshed. Without means the
repo is smaller and packaging can sometimes be more straightforward with
that approach.

If nobody else weighs in on this within a few days, I'd suggest you just
go ahead and import into a team-accessible git repo as you see fit.

> 1.) Fix RC bugs in mysql-5.1

Can we skip this altogether? 5.1's days are numbered. Lets just make
sure they're not duplicated in 5.5.

> 2.) implement new debian/rules in mysql-5.5
> 3.) Push mysql-5.5 into unstable
> 4.) Start work in on eliminating any piuparts style issues.
> 
> **** FREEZE *****************
> 
> 5.) Prepare git based 'mysql' package incorporating a 5.5 master branch 
> and a 5.6
> branch.
> 6.) Release the 5.6 branch to experimental
> 
> **** UNFREEZE ***************
> 
> 7.) Remove mysql-5.1 from testing

Id move this step to 4 and pause there to let 5.5 get into testing. I
don't want to have two versions in unstable/testing for longer than is
absolutely necessary. A lot of the necessary work to deprecate 5.1 has
been done already, I reported bugs where people were build-depending on
libmysqlclient15/16-dev and I only found 1 or two places where there
were explicit depends on mysql-(client|server)-5.1 packages and those
have been fixed to just use mysql-client or mysql-server.

I'll be working on getting 5.5 ready for unstable next week. I have not
had a chance to look at your rules file, but I'm excited to move forward
with some modernization. I totally agree with doing it incrementally and
switching to dh_install once the other bits prove solid.

> 8.) Must be satisfied that piuparts are resolved
> 9.) Replace mysql-5.5 with mysql and lots of Provides clauses so that 
> 5.5 is still available virtually.