List:Internals« Previous MessageNext Message »
From:Mats Kindahl Date:October 3 2009 5:55am
Subject:Re: RFC: package group names / directory names
View as plain text  
Davi Arnaut wrote:
> Hi,
> A somewhat late reply :-)

Thank you David, now we have at least two proposals. :)

> On 10/2/09 5:34 AM, Mats Kindahl wrote:
>> Hi again,
>> Given that there have been no comments on this for almost three weeks
>> and we
>> need to start moving forward, I arbitrarily pick the name "pkgs"
>> because it is
>> short and sufficiently general. If the need arises, we can always
>> create other
>> package groups later.
>> If anybody object to the choice of name, please reply.
>> /Matz
>> Mats Kindahl wrote:
>>> Hi all,
>>> I would like to thank you all for the comments I received on the
>>> draft for
>>> creating a physical structure. We made some changes to the proposal
>>> as a result
>>> of those comments, but the general structure remained the same.
>>> As part of the continuing work to implement this, the server will be
>>> partitioned
>>> into packages and potentially be organized into package groups. A
>>> package group
>>> is essentially a directory where a set of packages are put.
>>> To be able to distinguish between "unpackaged" and "packaged" code it is
>>> desirable to move the files from the sql/ directory into separate
>>> directories.
>>> Question is what we should call this or these directory/-ies?
>>> Some ideas:
>>> pkgs/
>>> packages/
>>>    Short and long version of a generic name. It is an advantage if
>>> packages do
>>>    not have to be moved around if their roles change (for example,
>>> packages that
>>>    are common to both the client and the server can be put parallel
>>> to the
>>>    packages that need them).
>>> server/
>>>    More informative, but the question is if all packages will be
>>>    for the server and the server alone. There is already a client/
>>> directory, so
>>>    this kind of parallels that.
>>>    It does introduce some problems on what to do with packages that
>>> are generic
>>>    and for, e.g., both the server and the client. A separate package
>>>    group/directory?
> I prefer this one. pkgs sounds confusing with packaging stuff and is not
> historically common. I prefer server/component.

It is a good point that it can be confused with, for example, a Debian package,
so maybe "server" is a better alternative for the package group directory.

>>>    And where does libmysqld ends up in all this? Is is it a server or
>>> something
>>>    else?
> server/embedded

Of of the things that I find most disturbing about the embedded version is that
it requires a full re-compile to work. A better model would be to not have
conditional compiles embedded in the code at all, and instead rely on
constructing, e.g., the embedded server by just picking the right components and
turning that into an archive.

The disadvantage would be that it require some more thinking when constructing
the server, since it would not be possible to "remove" part of a file for a
specific configuration, but that the separation has to be on a file basis.

If this can be accomplished, then the embedded server would not be a separate
directory, but rather just a separate target in the Makefile that builds an
archive consisting of the components that are required for the embedded server.
The code specific for the embedded server would be a separate package, as you
say above, and be put in the archive for the embedded server.

Just my few cents,
Mats Kindahl
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
RFC: package group names / directory namesMats Kindahl10 Sep
  • Re: RFC: package group names / directory namesMats Kindahl2 Oct
    • Re: RFC: package group names / directory namesDavi Arnaut2 Oct
      • Re: RFC: package group names / directory namesMats Kindahl3 Oct
        • Re: RFC: package group names / directory namesKonstantin Osipov21 Oct
          • Re: RFC: package group names / directory namesMats Kindahl21 Oct