Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Aug 2012 23:27:54 +0200
From:      Polytropon <freebsd@edvax.de>
To:        vermaden <vermaden@interia.pl>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: I Can Has Packages?
Message-ID:  <20120819232754.641a7eb2.freebsd@edvax.de>
In-Reply-To: <lvdsbvuwmpbmllonsvhr@dwkb>
References:  <mstfdvylnhedwhomycce@vqhb> <20120819213854.50408ec7.freebsd@edvax.de> <lvdsbvuwmpbmllonsvhr@dwkb>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Aug 2012 22:54:52 +0200, vermaden wrote:
> "Polytropon" <freebsd@edvax.de>:
> > On Sun, 19 Aug 2012 20:33:49 +0200, vermaden wrote:
> > > HI,
> > > 
> > > OpenBSD seems to have packages for everything, even
> > > for LAME (audio/lame), why FreeBSD can not provide
> > > package for LAME the same way as OpenBSD does?
> > 
> > j00 CAN haz pakagez. =^_^=
> > 
> > Packages for _everything_ is impossible because of the many
> > options that may or MAY NOT fit your needs, so things have
> > to be set at compile time. Just imagine how many different
> > packages you would have to host for OpenOffice!
> > 
> > In the past, "pkg_add -r de-openoffice" would have given
> > you a full-featured german version of OpenOffice, even
> > including a dictionary. Today, it's not that easy anymore.
> 
> The OpenBSD team serves these 'complicated' packages
> by using *flavours* and *subpackages*, packages or their
> parts compiled with different options, its described in the
> OpenBSD FAQ here: http://openbsd.org/faq/faq15.html
> 
> | 15.2.3 - Finding packages
> | 
> | (...)
> | 
> | You will notice that certain packages are available in a
> | few different varieties, formally called flavors. Others
> | are pieces of the same application which may be
> | installed separately. They are called subpackages.
> | This will be detailed further in Using flavors and
> | subpackages but flavor basically means they are
> | configured with different sets of options. Currently,
> | many packages have flavors, for example: database
> | support, support for systems without X, or network
> | additions like SSL and IPv6. Every flavor of a package
> | will have a different suffix in its package name. For
> | detailed information about package names, please
> | refer to packages-specs(7).

Interesting. That should work for packages with not so
many options. Opera has, if I remember correctly, 4 options,
resulting in tons of different dependencies; mplayer has
more options than you can fit on one screen (while we
assume the screen has 24 or 25 lines). It's an easy task
to calculate for a package with n options, each can be
set or not set, how many packages would have to be built
and served. :-)

I just assume providing packages for every imaginable
combination requires lots of resources. As an example
take OpenOffice: Every language variant, then integration
with KDE, Gnome, or none of them, and printing support
(I think). That would be many hours of compiling, and
lots of storage space needed (note: current _and_ older
packages are needed, plus supported architectures).



> > There are also ports that draw a massive slew of dependencies.
> > Some of them are of minor importance, like documentation that
> > urges you to install LaTeX. If that's the default the package
> > has been created from, installing it will bring teTeX to your
> > system too, even if _you_ don't need it.
> > 
> > Also consider programs like mplayer that can have a lot of
> > codecs. Because it's illegal in the U.S. to listen to MP3,
> > those may not be included. :-)
> > 
> > Okay, you get the idea: There may apply "shipping restrictions".
> > If I remember correctly, there has been such an issue for lame
> > in the past, but I thought that it would have been resolved.
> > When trying "make package", it was not possible, and there
> > also was not package for use with pkg_add. You _had_ to compile
> > it yourself because the terms of use told so.
> > 
> > The ports collections has a specific field in Makefile that
> > gives you information about such issues:
> > 
> > RESTRICTED=     patent issues, see http://www.mp3licensing.com/
> > 
> > So if OpenBSD serves a lame package (I mean a package containing
> > lame), you should ask them in how far they have an agreement that
> > allows them to do so, in comparison to what patent issues prohibit
> > doing the same on FreeBSD.
> 
> The OpenBSD port from here: http://openports.se/audio/lame
> 
> Has its description of LAME as a *educational* tool, maybe that is
> the reason why they provide package for LAME:
> 
> | LAME is an educational tool to be used for learning about MP3
> | encoding.  The goal of the LAME project is to improve the psycho
> | acoustics, quality and speed of MP3 encoding.
> 
> My buddy has sent email to OpenBSD LAME port maintainer with
> question why they can distribute that without concerns, I will let
> You know if he gets the answer.

That's really a good reason to avoid the restriction. I think
some specific kind of agreement has to be made to have this
declaration take effect and allow packaging the software.

There are other ports that don't have equivalents on FreeBSD.
A good example is Java. While I think it's possible to
package the software (the "make package" command), the
current vendor or Java (no idea who is it today) forces
you do manually download the sources and put them into
/usr/ports/distfiles, requiring you to interactively
agree with their terms of use.



Now keep working harder and carry a towel. =^_^=




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120819232754.641a7eb2.freebsd>