Gentoo Forums
Gentoo Forums
Quick Search: in
Constructive Portage Criticism
View unanswered posts
View posts from last 24 hours

rackathon
 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
deLockloire
n00b
n00b


Joined: 10 Dec 2003
Posts: 62

PostPosted: Thu Jan 22, 2004 12:10 am    Post subject: Constructive Portage Criticism Reply with quote

I feel a little bit confused when it comes to the function and the advantage of the USE flags in the portage system. When I met with the problems I'm going to describe, I asked my roomate, who uses FreeBSD BTW, how these things work under his system, so at certain points, I'll use that system as a reference. I'm going to attempt to gather everything that is not clear, or what I found confusing.

1) the options that can be set are program specific (meaning that each and every program can have its own special / unique costumization options for compilation. This implies 2 things
1.1) With a generously optimistic estimation, Gentoo should have at least a few hundred USE flags, which doesn't help the user when s/he is trying to costumize the system, because s/he has to keep a considerable amount of flags in mind.
1.2) If there're no USE flags for certain compile options, the costumizability suffers it. How can one set this, for instance, with USE flags (i don't say it cannot be done, but it's certainly not clear how):
Code:
mplayer makefile:
# WITHOUT_RUNTIME_CPUDETECTION
# default: undefined
# by default, mplayer is built with support for changing the used cpu
# instruction set while playing. This is necessary for package building.
# If you want to compile a specific version of mplayer working faster
# but only on your cpu type, then define this knob.
# If you define this, there are several additional knobs to explicitly
# disable some possible CPU features. See below

2) It seemed to me that, concerning compilation options, the USE flags should help the user to make the compilation automatic, i.e., without any user intervention. However, I have to check my USE flags for a lot of (or each) program to see whether there're options I should check for good functionality. The USE description guide, however, is not a very great help in my endeavors. For instance, I emerged KDE, and later I found out that I have no nsplugin support at all. I searched the forum only to find out that the motif USE flag wasn't enabled when I compiled. So now I have to recompile. The motif support, if I remember correctly, is enabled in the /etc/make.profile/make.defaults, but after reading the USE description through carefully, I disabled it and many others in my make.conf after attempting to compile mc (see point no. 3). This is what is said about the motif in the use.desc:
Code:
motif - Adds motif support (x11-libs/openmotif x11-libs/lesstif)
Believe me, this much I could figure all by myself. On FreeBSD, this is what you have in the Makefile, and see before the extraction of the file (apart from ECHO blahblah, of course :):
Code:
7pre-extract::
        @${ECHO_MSG}
        @${ECHO_MSG} "If you want to compile with Motif support,"
        @${ECHO_MSG} "hit Ctrl-C right now and use \"make WITH_MOTIF=yes\""
        @${ECHO_MSG}
        @${ECHO_MSG} "Motif is used for Netscape plugin compatibility."
        @${ECHO_MSG}
.endif # defined(WITH_MOTIF)
Note that it also says what is the current option. And I'll know what motif is for. Just check how many of the problems turns out to be due to the misconfiguration of the USE flags.
3) I don't see how the portage decides which packages are sensible to install (regardless or USE settings) and which are not. For instance, after my initial installation of Gentoo, I decided to emerge midnight commander. More or less, this is what the "emerge mc" wanted to install for me (note that some of these programs were already up at that time, so this list is not entirely faithful):
Code:
[ebuild  N    ] sys-devel/patch-2.5.9
[ebuild  N    ] sys-devel/gettext-0.12.1
[ebuild  N    ] sys-devel/gnuconfig-20030708
[ebuild  N    ] sys-devel/libtool-1.4.3-r3
[ebuild  N    ] sys-devel/m4-1.4-r1
[ebuild  N    ] sys-devel/bison-1.875
[ebuild  N    ] sys-apps/sed-4.0.9
[ebuild  N    ] sys-apps/texinfo-4.6
[ebuild  N    ] sys-libs/zlib-1.2.1-r2
[ebuild  N    ] dev-python/python-fchksum-1.7.1
[ebuild  N    ] app-arch/bzip2-1.0.2-r3
[ebuild  N    ] app-shells/bash-2.05b-r9
[ebuild  N    ] sys-libs/readline-4.3-r5
[ebuild  N    ] dev-libs/openssl-0.9.7c-r1
[ebuild  N    ] sys-libs/db-1.85-r1
[ebuild  N    ] sys-libs/gdbm-1.8.0-r5
[ebuild  N    ] dev-libs/expat-1.95.7
[ebuild  N    ] dev-lang/python-2.3.3
[ebuild  N    ] dev-java/java-config-1.2.4
[ebuild  N    ] sys-libs/lib-compat-1.3
[ebuild  N F  ] dev-java/sun-jdk-1.4.2.03
[ebuild  N    ] sys-libs/db-4.1.25_p1-r3
[ebuild  N    ] sys-apps/groff-1.18.1-r4
[ebuild  N    ] sys-devel/libperl-5.8.3
[ebuild  N    ] dev-lang/perl-5.8.3
[ebuild  N    ] sys-devel/autoconf-2.59
[ebuild  N    ] sys-devel/automake-1.7.8
[ebuild  N    ] sys-apps/cronbase-0.2.1-r3
[ebuild  N    ] sys-apps/man-1.5m
[ebuild  N    ] sys-apps/help2man-1.29
[ebuild  N    ] sys-apps/coreutils-5.0.91-r4
[ebuild  N    ] sys-apps/debianutils-1.16.7-r4
[ebuild  N    ] sys-apps/portage-2.0.50_pre16
[ebuild  N    ] sys-devel/gcc-config-1.3.4
[ebuild  N    ] sys-devel/binutils-2.14.90.0.8
[ebuild  N    ] sys-devel/gcc-3.3.2-r5
[ebuild  N    ] sys-apps/gawk-3.1.3-r1
[ebuild  N    ] sys-kernel/linux-headers-2.4.21-r1
[ebuild  N    ] app-crypt/hashalot-0.1.0
[ebuild  N    ] sys-devel/flex-2.5.4a-r5
[ebuild  N    ] dev-libs/glib-1.2.10-r5
[ebuild  N    ] sys-apps/miscfiles-1.3-r1
[ebuild  N    ] sys-libs/cracklib-2.7-r8
[ebuild  N    ] sys-libs/pam-0.77
[ebuild  N    ] sys-apps/shadow-4.0.3-r10
[ebuild  N    ] sys-apps/pam-login-3.14
[ebuild  N    ] sys-apps/util-linux-2.12-r4
[ebuild  N    ] sys-apps/baselayout-1.8.6.12-r3
[ebuild  N    ] sys-libs/glibc-2.3.3_pre20040117
[ebuild  N    ] sys-libs/ncurses-5.3-r5
[ebuild  N    ] dev-util/pkgconfig-0.15.0
[ebuild  N    ] dev-libs/glib-2.2.3
[ebuild  N    ] media-libs/libpng-1.2.5-r4
[ebuild  N    ] x11-base/opengl-update-1.5
[ebuild  N    ] media-libs/freetype-2.1.5
[ebuild  N    ] x11-misc/ttmkfdir-3.0.9-r1
[ebuild  N    ] app-arch/unzip-5.50-r2
[ebuild  N    ] sys-apps/ed-0.2-r3
[ebuild  N    ] media-libs/fontconfig-2.2.1
[ebuild  N    ] app-arch/cabextract-0.6
[ebuild  N    ] x11-base/xfree-4.3.0-r3
[ebuild  N    ] sys-fs/e2fsprogs-1.34-r1
[ebuild  N    ] sys-libs/gpm-1.20.1
[ebuild  N    ] sys-libs/slang-1.4.9
[ebuild  N    ] app-misc/mc-4.6.0-r4

This was the time when I decided to remove a lot of flags in my make.conf. I only wanted the midnight commander, certainly not Xfree or openGL. Q: Does port install, for instance, alsa support for mplayer (because of the auto config script) even if I had it disabled in my make.conf?
4) Also, I found the nature of USE flags very messy. See why:
4.1) Some flags seem to be CFLAG settings: 3dnow, sse, mmx, etc. (doesn't the CFLAG option takes care of this already?)
4.2) Some flags are to install userland utilities. Such is the cdr option. What's more, if I'm not mistaken, these flags make portage to install utility packages as dependencies and that is no good.
4.3) Some flags are functionality extensions, which puts up libs for a certain functionality for the given program (alsa, arts, etc.)

5) The descriptions of the certain packages are not very abundant either. It also takes a lot of time to search through the descriptions. Is there a way I can make a database of the descriptions, so the search doesn't take that long? I wanted to search for localized packages (so that my mother would be comfortable) and I found nothing. I know that the packages exist, but it was not very easy to find out which packages are the ones I was looking for (but, of course, this is also due to my lack of knowledge on naming conventions [i.e., i18n]). Below is the port convention behind BSD:
Code:
>>ls -lh /usr/ports/multimedia/mplayer/
total 26
-rw-r--r--  1 root  wheel    15K Dec 23 22:48 Makefile
-rw-r--r--  1 root  wheel   137B Nov 14 03:22 distinfo
drwxr-xr-x  2 root  wheel   512B Jan  6 15:09 files
-rw-r--r--  1 root  wheel   355B Jan 22  2003 pkg-descr
-rw-r--r--  1 root  wheel   437B Sep 28 19:58 pkg-message*
-rw-r--r--  1 root  wheel   1.4K Mar 26  2003 pkg-plist

In the Makefile, one can see every options the given program will accept. In pkg-descr, one can see a detailed description of the package, distinfo is the namesake of Gentoo's Manifest, pkg-list says the path where the files will be installed, while in pkg message contains message to be displayed after port installation, usually tips on how to run the prog. This is what BSD gives for the equivalence of emerge --searchdesc hungarian:
Code:
>>make search key=hungarian | grep ^Port # we only need the port name
Port:   hu-phone-20020622
Port:   hu-zipcodes-20020622
Port:   hu-ispell-0.99.3
Port:   hu-jdictionary-eng-hun-1.4
Port:   hu-jdictionary-eng-hun-expr-1.4
Port:   hu-kde-i18n-3.1.4
Port:   hu-koffice-i18n-1.2.1
Port:   hu-ooodict-HU-1.2

Therefore, what seems to be the greatest problem is the fact that in order to get system of my liking I have to gather very much undocumented information (usually after compilation), and I have to put so much work into using the USE flags properly (and costumize my progams) that this defeats the overall purpose of the portage system (which is meant to simplify things). I have to get all USE flags minus the ones I don't need (costumized every time I install a relatively big package). The effort I have to put into making this work is not much less than learning the dependency tree of the programs I'd use under Slackware. Alternatively, I can just discard the thought of costumization. Again, this is no good, since the USE flag system is marketed for its constumizing power. Something here is not right, so what do I miss, folks?
Back to top
View user's profile Send private message
Nu-Bee_4VR
Apprentice
Apprentice


Joined: 12 Dec 2003
Posts: 245

PostPosted: Thu Jan 22, 2004 12:47 am    Post subject: Reply with quote

I am new to Gentoo but this might help....

As I understand it, programs that you emerge will have certain USE flags that are default to them...try the command:

Code:
# emerge -pv <something>


...and it will list the default flags.

The make.conf is to add/remove flags that you want special...

Emerge ufed and it might help clear things up for you. Notice that it only adds the USE flags that you choose which are not already in one of the default files.

Code:
# emerge ufed

_________________
-Joseph-

In the majority of any Democrat/Republican or Liberal/Conservative Debates on TV, pay close attention to how much MORE often the Liberal/Democrat butts in and rudely talks 'over' the Conservative/Republican.

Think about it...
Back to top
View user's profile Send private message
tomk
Administrator
Administrator


Joined: 23 Sep 2003
Posts: 4549
Location: Sat in front of my computer

PostPosted: Thu Jan 22, 2004 9:10 am    Post subject: Reply with quote

As well as using the -v flag with emerge you can use etcat (part of gentoolkit) to give you descritptions for USE flags of each package:

Code:
etcat -u package_name


I also have a look at the ebuilds, often it will give you more of an idea of what the USE flag is for. e.g. Wether it jus adds compile time options or it installs extra packages.

For the package descriptions use qpkg:

Code:
qpkg -i package_name


add -I if you're only looking for installed packages, this reduces the search time dramatically. It's all based on the info in /var/db/pkg/ and /usr/portage

Portage doesn't just make things easier, it allows you to customise your installation exactly to your requirements, btu that means you'll have to play around with the USE flags.

Some of these problems will be fixed with portage 2.0.50, you will be able to specify USE flags per package
_________________
Search | Read | Answer | Report | Strip
Back to top
View user's profile Send private message
deLockloire
n00b
n00b


Joined: 10 Dec 2003
Posts: 62

PostPosted: Fri Jan 23, 2004 9:19 pm    Post subject: Reply with quote

Nu-Bee_4VR wrote:
try the command:
Code:
# emerge -pv <something>

thanks. i also use this feature. "ep" is an alias for this command for me. it's a good option, but unfortunately, it doesn't help any of the problems with the concept of use-flags. :(
Nu-Bee_4VR wrote:
Emerge ufed and it might help clear things up for you. Notice that it only adds the USE flags that you choose which are not already in one of the default files

what is it?
Back to top
View user's profile Send private message
rmbalfa
Apprentice
Apprentice


Joined: 15 Dec 2003
Posts: 200
Location: Illinois State University/Chicago

PostPosted: Fri Jan 23, 2004 9:30 pm    Post subject: Reply with quote

ufed really helped me out a lot
Back to top
View user's profile Send private message
ferringb
Retired Dev
Retired Dev


Joined: 03 Apr 2003
Posts: 346
Location: USA

PostPosted: Fri Jan 23, 2004 9:41 pm    Post subject: Reply with quote

for question 3 (determining what package is pulled in due to being depended on by another package), try out portage-2.0.50.

There is a thread floating around here somewhere by genone that details it better, but there is a new option --tree that will outputs the an indentation listing of which packages are being pulled in where.
_________________
I don't want to be buried in a pet cemetery. ~Ramones
Back to top
View user's profile Send private message
deLockloire
n00b
n00b


Joined: 10 Dec 2003
Posts: 62

PostPosted: Fri Jan 23, 2004 10:22 pm    Post subject: Reply with quote

tomk wrote:
For the package descriptions use qpkg:
Code:
qpkg -i package_name

add -I if you're only looking for installed packages, this reduces the search time dramatically. It's all based on the info in /var/db/pkg/ and /usr/portage

oh, well... sometimes i must seem very ungreatful, but believe me, i'm not. :) qpkg needs a package name as its argument, and thus, can only search in certain packages. what i meant above was that portage should be able to generate a database of the descriptions of the available packages, so that emerge --searchdesc doesn't take long. it's not *that* important, it'd be just a nice feature. generally i'd search for a program for a certain purpose. what i'd need, is the package name, so i wouldn't be able to give it to qpkg, would i? :)
tomk wrote:
you can use etcat (part of gentoolkit) to give you descritptions for USE flags of each package:
Code:
etcat -u package_name

but etcat doesn't do anything else than reiterate what is written in use.desc. it'd be a fair (and useful) option (etcat -u) if the use-flags were much better documented. see my example with the motif flag above.
tomk wrote:
I also have a look at the ebuilds, often it will give you more of an idea of what the USE flag is for. e.g. Wether it jus adds compile time options or it installs extra packages.

now we're closing. :) how do you know? the ebuilds are not renowned for being full of comments. it seems to me that unless you're very familiar with the certain libraries/packages and their use/function, you have little chance of knowing. but this is only a minor issue (or no issue at all, after all), and i think use-flags being a conceptual mess is something everybody can live with. :)
tomk wrote:
Portage doesn't just make things easier, it allows you to customise your installation exactly to your requirements, btu that means you'll have to play around with the USE flags.

i'd compromise with a commented ebuild as well. in my first post, you can see a quote from the freebsd mplayer makefile. in a makefile, every option which the given program will accept is covered in detail, so you can not only know what options are responsible for what in the given program, but also have absolute control over costumization, which i don't see to be attainable at all with USE flags under gentoo. either i miss something vital as concerning the use-flags concept, or the use-flags idea is not as great as it's being marketed, since it cannot serve the very purpose it is created for. (this is of course not entirely true, but the use-flags are said to be the ultimate advantage over the [free]bsd port system, so u might understand my disappointment after this turns out to be entirely false]. either way, something is wrong. in the former case (i.e., i don't grasp the use-flag concept), i just need a little explanation, and i'd welcome it. in the latter however, i stand confounded as everyone seems to love use flags for it's constumizing power. i feel a great deal of over-enthusiasm concerning the issue. there're a lot of problems concerning use-flags (usually because of the lack of appropriate documentation [put or echoed in a useful/appropriate time/place]), and people who have to reemerge kde for this doesn't say "gosh, why isn't it documented normally?!", but start loving the use-flags instead. i'm amazed over this lack of vision. criticism is not a thing to be avoided, and problems are not to be hidden. don't get me wrong, i'm using gentoo, and i intend to keep on using it, that is why i'm putting this effort into it.
tomk wrote:
Some of these problems will be fixed with portage 2.0.50, you will be able to specify USE flags per package

i'm curious how that will be solved. also, if it also means that there'll be use-flags for every possible option a program can take (absolute costumization), that will be nice to configure. but we'll see.
Back to top
View user's profile Send private message
ecatmur
Veteran
Veteran


Joined: 20 Oct 2003
Posts: 3595
Location: Edinburgh

PostPosted: Thu May 13, 2004 9:32 pm    Post subject: Reply with quote

1.2: runtime cpu detection is disabled in the mplayer ebuild. This is because it is useless on a source-based distro.

2: well, eh. Perhaps the kdebase (?) ebuild should mention that motif is needed for the nsplugin to work in the pkg_setup ("use motif || einfo "If you want netscape plugin support, blah..."). File a bug?

3. The X interface to mc is governed by the (surprise!) X USE flag. Ditto for alsa and mplayer.

4. You list three categories, but I'm not sure that it's that clear cut. WRT cdr, to me such things make sense; I want cdr support but I don't care which program I use to get it to work.

5. Maybe esearch? I don't find the descriptions tell me anything I wouldn't know anyway, esp. after googling for related packages.
WRT i18n, Gentoo takes the position that full l10n is the way to go (but do remember to enable the nls USE flag). However there is some effort being made to enable a LINGUAS or similar variable to allow selective installation of language files. IMHO disk space is cheap, .mo files aren't that large, and it's good to have them available should you ever need them.
WRT the BSD ports structure, surely this takes away the potential to have multiple versions of packages available in Portage, and also to tailor output messages to the build environment. AIUI BSD despite being source-based is far more restrictive on which versions you are allowed to have installed than is Gentoo. e.g. pkg-list, which can only ever be a guess on a source distro.

Well, we have per-package USE flags now and it hasn't led to an explosion of USE variables. IMO the USE system is only an advantage over binary distros, the advantages of Portage over BSD Ports lie elsewhere - more flexible in many ways, including kernel, package versions, ebuilds as opposed to Makefiles, easier to add your own packages, etc.
_________________
No more cruft
dep: Revdeps that work
Using command-line ACCEPT_KEYWORDS?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum