[yocto] All incompassing documentation

Jeff Osier-Mixon jefro at jefro.net
Wed Sep 19 13:45:17 PDT 2012


I'm afraid "source tarball" doesn't quite work, as not all are
required to be tarballs, e.g. if something is in a git repo or in a
local CVS repo.

Can it be true that there is no single term that refers to the
collection of pieces that, when built, create a discrete package?

On Wed, Sep 19, 2012 at 8:50 AM, Brian Lloyd <blloyd at familyhonor.net> wrote:
> I would like to point out Yocto's own documentation uses it for two
> separate items, which is the point I was making.  Neither of which are
> source tarballs....
>
> It is a product produced by Yocto.
> It is the items to be installed from the host system.

I think these actually refer to the same thing. "Packages" are
products of the Yocto Project build process whose purpose is to be
installed on the target. They are "packaged" using a specific format
(.rpm, .deb, .ipk). This is a universal development term, at least
within the wider Linux community, not a specific Yocto Project term.
Unless I misunderstand what you are saying?

> That may be right, but if so, we can't say that for Yocto it only means
> the first, as we use it for the second as well.  If we want it to only
> be the first, then we must use a different term for the second, such as
> host applications, and the user should be notified of the unusual word
> choice and why early in the documentation.  I believe there are several
> locations where terms are explained already in the documentation, even
> if we later use the term in a way other than that identified as it's
> meaning (3.4. Yocto Project Terms comes to mind).  Discussing Package
> meaning there, perhaps we should identify the term that will be used for
> host package, or how we will identify when the term is used with a
> different meaning than the one just given.

There shouldn't be any applications on your host (meaning: built for
your host) that end up being installed on the target. There may be
"packages" that you have downloaded that you'd like to install on your
target, but that

> Or if we concede that packages is what the user expects to see when
> discussing what to install, we need to disambiguate in some way to
> differentiate the two uses.  Indexes are good at this.  The biggest
> advantage to an index over straight search is that author's can use
> context to differentiate the different uses when a word has them.
> Another option could be prepending to both the context at each location
> used, so we use Yocto package and host package or where we always prefix
> context to one of the two for every use.  However, doing only one with a
> context makes for more manual searches, where we are making a document
> with the goal of making searching for information more effective.

Can you tell us what you mean by "host package"?

>
> On Tue, 2012-09-18 at 21:02 -0700, Jeff Osier-Mixon wrote:
>> <snipped>
>>
>> On Tue, Sep 18, 2012 at 12:04 PM, Trevor Woerner <twoerner at gmail.com> wrote:
>> > On Tue, Sep 18, 2012 at 2:23 PM, Brian Lloyd <blloyd at familyhonor.net> wrote:
>> >> Most of my hits for such an item
>> >> discuss the packages I will need to install in my host distribution so I
>> >> can use the yocto project (not surprised, the danger of a term as vague
>> >> as packages).
>> >
>> > In bitbake/yocto/OE/etc. the term "packages" is not vague and has a
>> > very specific meaning: bitbake processes recipes to produce one or
>> > more packages. Some of these packages are then assembled into an
>>
>> This is quite true - but the term itself is overloaded. I have often
>> heard "package" referred to also as the collection of source code one
>> would use to create a given piece of software, e.g. "the busybox
>> package". This is no doubt the result of downloading numerous
>> "packages" from the net in binary form rather than source. It doesn't
>> help that there are "source packages" in the RPM world
>> (http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html) and in the
>> Debian world (http://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html),
>> so the confusion is natural.
>>
>> In OE-based systems like the Yocto Project, the term refers to the
>> results of a build rather than the ingredients. I agree with you that
>> we should continue to push the correct usage to unload the term.
>> Anyone have a good term for "source packages"?
>>
>
>
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org



More information about the yocto mailing list