All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Cc: yocto@yoctoproject.org
Subject: Re: Samba server?
Date: Tue, 02 Apr 2013 08:13:08 +0100	[thread overview]
Message-ID: <7803001.8VMXG1vLlf@helios> (raw)
In-Reply-To: <CC8EC8ACB2884AB0BBAF61C7FAF19D47@PAULD>

On Monday 01 April 2013 16:42:46 Paul D. DeRocco wrote:
>  What I don't see is any info on the recipes, beyond name and version
>  number.
> I don't see a list of packages they produce. For instance, doing "bitbake
> -e samba", and then looking at the PACKAGES variable, shows the following
> list:
> 
>     libwbclient
>     libwinbind
>     libwinbind-dbg
>     winbind
>     winbind-dbg
>     libnetapi
>     libtdb
>     libsmbsharemodes
>     libsmbclient
>     libsmbclient-dev
>     cifs
>     cifs-doc
>     swat
>     samba-dbg
>     samba-staticdev
>     samba-dev
>     samba-doc
>     samba-locale
>     samba
> 
> I'm not sure what got included when I added "samba" to my IMAGE_INSTALL
> variable, but I assume samba and winbind are required, but the other things?
> To an end user like me (someone who just wants to build a distro with
> certain capabilities, and then get back to the real work of application
> development), the following sorts of questions occur:
> 
>     What choices are provided by each package?
>     If something is included in the build, can I do without it?
>     If something isn't included in the build, should I add it?
> 
> To be a real turn-key system, each recipe needs a page, or two, or three, of
> human-written (not script-produced) explanation of what options the recipe
> has, what they correspond to in user terms, and how they can be selected or
> deselected. Without that, the recipe really isn't "documented" in the
> conventional sense.

I guess that would be helpful, but I don't know if we have the resources to
document that for every recipe. Usually that information is already available
upstream. It could be that we can get to this point later on.

> When I added samba to core-image-base-cedartrail-nopvr, the image got vastly
> bigger. I wouldn't think the ability to do Windows file sharing would be
> comparable in size to the rest of the system. 

As I understand it Samba 3 itself (upstream) is an special case in this regard
- it has a deficiency where it includes a substantial portion of its library
code in every executable, of which Samba provides quite a few, making
it quite large indeed. If you look at these executables on your standard
Linux distribution you'll probably find they are similarly sized. Last time
I searched about the problem it was acknowledged by the developers but
they didn't seem overly interested in solving it at the time, which is
unfortunate. Hopefully Samba 4 is better in this regard. Here is the
thread:

http://lists.samba.org/archive/samba/2009-October/151096.html

> Did it add tons of man pages which no one will read, because it's an
> embedded system?

In the absence of bugs, we do package documentation separately (*-doc
packages) so that is unlikely to be the case.

> Did it add a
> client which I don't need, or just the server which I do need? Did it add
> libraries to the target that will never be used? Eventually, I'll figure
> this out, but I'm spending weeks and weeks on this, which is making this a
> very expensive project. Perhaps I should have just hired someone else to do
> it for me.

FWIW, we do strive to make things as minimal as we can; that's why we split
things up into so many packages. You've done the right thing in just adding
the main "samba" package to the image, it's just that Samba itself is quite
large and beyond patching the source or splitting packages further there's not
a lot that can be done about it.

FYI if you're interested in some analysis of the contents of final images you
may find buildhistory useful. There is a section of the manual about it here:

http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#maintaining-build-output-quality

Also, I know this doesn't help you much right now, but FYI we plan to
build more powerful image contents analysis tools into Web Hob, which
will be a web-based frontend to the build system.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2013-04-02  7:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 23:31 Samba server? Paul D. DeRocco
2013-03-07 10:40 ` Martin Jansa
2013-03-07 18:22   ` Paul D. DeRocco
2013-03-07 18:29     ` Martin Jansa
2013-03-07 22:29       ` Paul D. DeRocco
2013-03-07 22:42         ` Martin Jansa
2013-03-27  8:09           ` Paul D. DeRocco
2013-03-27  9:03             ` Anders Darander
2013-03-27 22:12               ` Paul D. DeRocco
2013-03-28  2:10                 ` ChenQi
2013-03-28  3:10                   ` Paul D. DeRocco
2013-03-28  3:24                     ` ChenQi
2013-03-28  5:55                     ` Anders Darander
2013-03-28  6:05                       ` Paul D. DeRocco
2013-04-01  9:32                     ` Paul Eggleton
2013-04-01 23:42                       ` Paul D. DeRocco
2013-04-02  7:13                         ` Paul Eggleton [this message]
2013-03-28 20:33                   ` Trevor Woerner
2013-03-28 21:35                     ` Paul D. DeRocco
2013-03-28 21:44                       ` Trevor Woerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7803001.8VMXG1vLlf@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=pderocco@ix.netcom.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.