On Monday 20 June 2011 22:40:48 Dennis Jacobfeuerborn wrote:
> On 06/20/2011 08:31 PM, Kevin Fenzi wrote:
> > On Mon, 20 Jun 2011 21:11:17 +0300
> >
> > Marian Marinov<mm@yuhu.biz> wrote:
> >> I have thought about building both MySQL packages as a separate
> >> daemons but the problem is that since they are one and the same, they
> >> use the same port ,the same configuration files and the same data
> >> directories.
> >>
> >> Althou that could be changed with a few simple patches this would
> >> make them somewhat cripled.
> >> Also the userland tools use the same configuration files (~/.my.cnf)
> >> which will complicate things even more.
> >>
> >> Is it possible for the EPEL policy to bend a little here for at least
> >> one of these packages ?
> >
> > I suppose these could fall under the compatibility packages thing we
> > have been talking about for things like newer boost or the like.
> >
> > http://fedoraproject.org/wiki/Packaging:Conflicts#Compat_Package_Conflict
> > s
> >
> > I think we are drving down a slippery slope here tho.
> > A downside of this kind of thing also is packages or people who do 'yum
> > install /usr/bin/mysqld'. They aren't really sure what they will get
> > there.

I agree here, when the exceptions become too many then they start to overrule
the policy.


>
> That doesn't look like much of a problem though. If you need something
> specific then you should install something specific. If on the other hand
> "anything that provides /usr/bin/mysqld" is good enough then you can't
> really complain.
>
> > I wonder if this wouldn't be better in IUS?
> >
> > Or talk with upstream about renaming things so it can parallel install,
> > and then perhaps we could change packages to need 'mysql-database' or
> > something that could get added as a virtual provides to all of these?
>
> The question is if the other upstreams consider themselves to be
> alternative implementations of MySQL and pledge to uphold compatibility or
> if they consider themselves to be forks of the original project. If it's
> the latter then they should live in their own space and change names of
> binaries, paths, etc. the same way drizzle did. If they are simply
> alternative implementations though this would probably have to be resolved
> using proper conflicts/provides in the rpm's.

For MariaDB I'll talk with the developers since at some point in time(soon)
they will be completely different then MySQL(they already did a few
renameings). And this may make them uncompatible with MySQL.

For Percona however, this is not the case. They use the sources provided by
Oracle and simply add the Google patches and their own engine patches. They
don't change anything else, which makes them a drop in replacement for MySQL
with a future plans to stay that way.

Regards,
Marian

>
> Regards,
> Dennis
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Tuesday 21 June 2011 00:43:30 Marian Marinov wrote:
> On Monday 20 June 2011 22:40:48 Dennis Jacobfeuerborn wrote:
> > On 06/20/2011 08:31 PM, Kevin Fenzi wrote:
> > > On Mon, 20 Jun 2011 21:11:17 +0300
> > >
> > > Marian Marinov<mm@yuhu.biz> wrote:
> > >> I have thought about building both MySQL packages as a separate
> > >> daemons but the problem is that since they are one and the same, they
> > >> use the same port ,the same configuration files and the same data
> > >> directories.
> > >>
> > >> Althou that could be changed with a few simple patches this would
> > >> make them somewhat cripled.
> > >> Also the userland tools use the same configuration files (~/.my.cnf)
> > >> which will complicate things even more.
> > >>
> > >> Is it possible for the EPEL policy to bend a little here for at least
> > >> one of these packages ?
> > >
> > > I suppose these could fall under the compatibility packages thing we
> > > have been talking about for things like newer boost or the like.
> > >
> > > http://fedoraproject.org/wiki/Packaging:Conflicts#Compat_Package_Confli
> > > ct s
> > >
> > > I think we are drving down a slippery slope here tho.
> > > A downside of this kind of thing also is packages or people who do 'yum
> > > install /usr/bin/mysqld'. They aren't really sure what they will get
> > > there.
>
> I agree here, when the exceptions become too many then they start to
> overrule the policy.
>
> > That doesn't look like much of a problem though. If you need something
> > specific then you should install something specific. If on the other hand
> > "anything that provides /usr/bin/mysqld" is good enough then you can't
> > really complain.
> >
> > > I wonder if this wouldn't be better in IUS?
> > >
> > > Or talk with upstream about renaming things so it can parallel install,
> > > and then perhaps we could change packages to need 'mysql-database' or
> > > something that could get added as a virtual provides to all of these?
> >
> > The question is if the other upstreams consider themselves to be
> > alternative implementations of MySQL and pledge to uphold compatibility
> > or if they consider themselves to be forks of the original project. If
> > it's the latter then they should live in their own space and change
> > names of binaries, paths, etc. the same way drizzle did. If they are
> > simply alternative implementations though this would probably have to be
> > resolved using proper conflicts/provides in the rpm's.
>
> For MariaDB I'll talk with the developers since at some point in time(soon)
> they will be completely different then MySQL(they already did a few
> renameings). And this may make them uncompatible with MySQL.

Ok this statement is wrong. I have just been convinced by the MariaDB devs,
that MariaDB will remain 100% compatible with the file formats of Oracle's
MySQL which automatily joins it with Percona. It is in the same situation.
MariaDB roadmap will introduce new storage engines and better query optimizer,
but everything that is myisam and innodb will be 100% compatible.


>
> For Percona however, this is not the case. They use the sources provided by
> Oracle and simply add the Google patches and their own engine patches. They
> don't change anything else, which makes them a drop in replacement for
> MySQL with a future plans to stay that way.
>
> Regards,
> Marian
>
> > Regards,
> >
> > Dennis

--
Best regards,
Marian Marinov
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Is it possible to add a small discussion about Percona and MariaDB to the
schedule of the next monday IRC meeting ?

Marian
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Thu, 23 Jun 2011 12:32:28 +0300
Marian Marinov <mm@yuhu.biz> wrote:

> Is it possible to add a small discussion about Percona and MariaDB to
> the schedule of the next monday IRC meeting ?

Sure.

Will you be able to attend?

Just add it at:

https://fedoraproject.org/wiki/EPEL_SIG

(at the bottom in agenda items)

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Thursday 23 June 2011 15:59:35 Kevin Fenzi wrote:
> On Thu, 23 Jun 2011 12:32:28 +0300
>
> Marian Marinov <mm@yuhu.biz> wrote:
> > Is it possible to add a small discussion about Percona and MariaDB to
> > the schedule of the next monday IRC meeting ?
>
> Sure.
>
> Will you be able to attend?
>
> Just add it at:
>
> https://fedoraproject.org/wiki/EPEL_SIG
>
> (at the bottom in agenda items)

Thank you, I added it.
I will be there, I stay in the #epel channel nick HackMan.

>
> kevin

--
Best regards,
Marian Marinov
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list