overblown ebuilds

jukka · Posted: Wed Feb 05, 2003 12:45 am Post subject: overblown ebuilds

hi,

IMO some ebuilds are overblown. they apply non-standard patches by default, depend on other packages which are not necessarily needed, etc. some examples:

net-dns/djbdns applies the fwdzone patch, which most people won't need (and, btw, may break existing dnscache installations...).
net-mail/qmail depends among other things on the 'checkpassword' and 'dot-forward' packages - needless in many cases; furthermore several patches are applied which (big-todo, big-concurrency) with the utmost probability nobody needs.

(i'm sure people who need the patches mentioned above definitely don't use an ebuild to build their software...)

i'd like to hear your opinion: should ebuilds

install software in a default manner with no enhancement patches (i.e. only bug-fixes), or should they
install as much enhancements as possible?

i definitely dislike the latter way, but it's already a fact for an increasing amount of ebuilds.

greetings, jukka

steveb · Advocate Joined: 18 Sep 2002 Posts: 4564

hoi jukka

heute war ein richtiges scheiss wetter in basel

now to your question:
i like the last way, but i would much much more prefere if i could enable/disable the options/patches/enhancements with USE values (aka: djbdns-fwdzone, qmail-big-todo, qmail-big-concurrency, etc) or the way alsa-drivers is working (aka: env ALSA_CARDS='bla bla' emerge alsa-driver).

cheers

SteveB (from ZH, but working offten in BS)

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

llornkcor · n00b Joined: 11 Oct 2002 Posts: 3

I would have to agree small minimal builds are needed. I tried emerging evolution. After dl'ing and installing nearly everything from gnome, I stopped it when it started downloading mozilla source. WTF is mozilla source needed for compiling evolution?!? heh I am not waiting to compile mozilla, when it is installed already.
SO, I have found, for bigger packages like evolution, kde or the like, downloading the traditional way is easier.

ljp

paul138 · Guru Joined: 09 Aug 2002 Posts: 370 Location: Ottawa, ON

There is also the issue of builds like MySQL and Samba.

Some of us got spoiled with packages like mysql-libs, mysql-dev, samba-libs etc. when using one or more of the other distribuions.

I spoke with one of the package maintainers here about splitting up some of these builds as they add much bulk to systems and he stated that it would not happen and that portage would become too large. While this is partially true, my hard drive can only take so much ;-)

Community thoughts?
_________________
Talk is cheap because supply always exceeds demand.

BlackBart · Apprentice Joined: 07 Oct 2002 Posts: 252

if you used USE settings for everything there would be WAY to many use flags and it would be a pain to set up.

knittel · n00b Joined: 29 Nov 2002 Posts: 50

And gdk-pixbuf wants gnome1 libs even if "-gnome" is specified. xscreensaver is an equal "mess". Why does it override settings (use gtk even if -gtk buit also -mozilla ....)

Specifying "-pam" has no effect on the very base system (though maybe an desings decision)

USE kerberos always (mostly for sure) assumes MIT. A pain for KTH users. virtual/krb5 or virtual/krb4 would solve.

I wonder, wether gentoo could have something like a "portage cleaning week", where inconsistencies or oddities are collected.
Maybe its developement is a bit too fast. Even though we all like "the latest and greatest(tm)", a two week freeze before 1.4 final could do wonders. Which would also ensure more proper testing to avoid troubles like seem to have occured with gcc-3.2.1-r6.

Just an Idea.

AlterEgo · Veteran Joined: 25 Apr 2002 Posts: 1619

[I know people are NOT gonna like this :wink:

]
It would be nice to have a graphical emerge/portage-tool, maybe something like Kportage (I have not seen it in a long time), extended with a panel where you can select the USE/IUSE options the ebuild has to offer by simply clicking on them.
It would function as an extention on the generic USE flags; allow you to make adjustments to the generic USE flags, but also give you control over ebuild-specifice options, like Mozilla building with- or without mail/pgp support , or including font-smoothing patches into Xfree.

That would be a lot easier than "reading" the ebuild beforehand.

pjp · Administrator Joined: 16 Apr 2002 Posts: 20067

I suspect that "reading" the ebuild beforehand is only temporary. Gentoo is still under alot of development. A GUI tool? Sure... then Gentoo has to pick an official GUI to support. That could get ugly (Gnome vs. KDE vs. blah blah blah).
_________________
Quis separabit? Quo animo?

really · Guru Joined: 27 Aug 2002 Posts: 430 Location: nowhere

ebrostig · Posted: Wed Feb 05, 2003 7:23 pm Post subject:

rac · Posted: Wed Feb 05, 2003 9:13 pm Post subject:

lostlogic's kernel ebuilds have a patch exclusion system like this - perhaps it could be adopted by other ebuilds if necessary.
_________________
For every higher wall, there is a taller ladder

AlterEgo · Veteran Joined: 25 Apr 2002 Posts: 1619

Carlo · Developer Joined: 12 Aug 2002 Posts: 3356

I think the pure (increasing) number of combinations of ebuilds, iuse and use flags maybe tend to be confusing one day. Something like a "portage cleaning week" sounds good, but I didn't know where to start. Though it's not my job. :wink:

What I would like to see is a emerge --iuse option, to view the iuse-flags and maybe a --ask option, to be able to decide interactive, which to negate.

To come back to jukka's question: I don't know which way I prefer. If you have an iuse flag for nearly every single included patch, caring for these flags would become uncomfortable. Going without any patches, could become uncomfortable, if you need a "common" patch, but the next update for security reasons leaves you with some incompatible sources. I think there is no best way to go for, but the developers of gentoo should bear in mind, that's sometimes better to apply a patch only, if a reasonable amount of users ask for it.

edit: Just want say that I dislike (patched or not) fat packages.

Carlo

jukka · Posted: Thu Feb 06, 2003 6:05 pm Post subject:

first of all: thank you guys for your replies.

i'm sure it's impossible - or at least very difficult - to satisfy everyone's needs when designing a os distibution. i just was annoyed with the fact that i had to install approx. 50% of my software manually, and all i got were colourful init scripts ;-) (no offense, devs, you're doing a good job)
...and because everybody is free to install another distro or to build a system from scratch i'm not about to complain...

knittel · n00b Joined: 29 Nov 2002 Posts: 50

Maybe we should't even start with iuse. Instead, maybe have an extra folder below make.profile, with a single file per affected software.

F.e. I could imagine this for alsa and mozilla very well. I believe, "iuse" is - or should - not be too common, so the amounts of files will be very managable. Most "work" will still be done by the "use" flags. Just options very special to a certain, singe software should go into "iuse". Like selection of oss-compatibility for alsa or decide wether or not to build mozilla with chatzilla.

I believe I've seen ports where "iuse" overrides "use" flags, or, at least specify options that also are standard to "use" flags. Like "IUSE gnome".
This should never happen, or well end up in a mess sooner or later. But then again, maybe I misinterpret the "iuse" Variable.

And, while we're at it. We need proper installpathes. Why must everythig go blindly into /usr ? If people have - for what reason ever - problems with installing X related stuff like windowmanagers into /usr/X11, the file thing explained above could handle an extra option, like "DEDICATED_DIR", which would install chosen software into /usr/program. Multiple installations of berklydb comes to mind, with /usr/db3, /usr/db33, /usr/db4 a.s.o. Despite, that mozilla should IMHO have its own dir as gnome should, too. Like kde does have. Why that, btw. ?

Robelix · Posted: Sat Feb 08, 2003 11:34 am Post subject:

bcavalieri · n00b Joined: 27 Sep 2002 Posts: 72 Location: Kansas City

Robelix · Posted: Sun Feb 09, 2003 1:00 am Post subject:

Carlo · Developer Joined: 12 Aug 2002 Posts: 3356

InvsbleChuck · n00b Joined: 17 Jul 2002 Posts: 28 Location: Brooklyn, NY

tecknojunky · Posted: Mon Feb 10, 2003 2:45 am Post subject:

I see that i'm not alone that complains about the lack of controls over individual ebuilds installations :wink:

I was happy to find the existience of ufed because you finally have a way to configure this infamous USE variable with values that have (at least) a description with each. But, who really can say what each of them have for impact on ant particular emerge? Not I. I'm beginning to take the habit now to go take a look at the ebuild "script" to be sure what's needed AND what's not.

I, for one, think a CUI (curse, slang, whatever) would be much needed. I would like to see the dependency resolved on a per package options selection. Say, if I emerge samba, a nice cui would permit me to activate/deactivate options like pam, kerboros, nfs, etc and, say I shoose kerboros support and it's not on my system, will add it as a dependency that would in turn show me a cui for kerboros oarticular options and dependencies. This could also be extended to setting compilation flags on a per package also.

I don't find it logical to set USE options that are system wide because, it simply does not reflect the reality of what we need (same for the compiler flags). So, like many, I end up fudging ebuilds, setting variables before the emerge command and never do "emerge world" without a -p option because it's simply too risky.

But I have doubt to see this anytime soon. I have heard that the development team is anchord deep to keep portage based on python dispite it's limitations. I'm no Python expert but I have seen many tools for C (C++) integration in Python and I think that some of Portage components would greathly benefit from compiled code and/or the use of C libs (mainly, all that is relating to search a dependency tree or ordering the initialisation scripts). Believe me, for the heck of it, I installed Gentoo on a 486 and just the little Python part that finds out how to order the initialisation scripts (when you boot) takes almost 2 minutes, emerge -p whatever will take close to 5 minutes before printing something.

I wish portage's development would not be closed amoung a small group of developpers.
_________________
(7 of 9) Installing star-trek/species-8.4.7.2::talax.

guero61 · l33t Joined: 14 Oct 2002 Posts: 811 Location: Behind you

I think the original issue still remains: sometimes, but not always, ebuild writers add in what they "think would be nice" or think everyone else wants or uses. Idealistically, I believe they should follow an "absolute minimum" standard. Install and depend on only what is absolutely necessary for the program to run in the most minimalistic setting possible.

nbensa · Posted: Mon Feb 10, 2003 4:25 am Post subject:

tecknojunky · Posted: Mon Feb 10, 2003 6:02 am Post subject: