It seems like somebody read my previous post about using Gentoo for building embedded-system filesystems as a mission that would increase the complexity of the work for Gentoo, and would waste time for no god reason. And if you look at the post, I do call that bullshit, for a good reason: proper dependencies are not going to increase complexity of either ebuilds nor the work needed by the packager, they are only extensions to the standard procedure.
Let’s take, as example, the zlib package: it’s part of the system set and some people say that this is enough to ignore adding it to the dependencies. Why? Well that’s a very good question: most of the times the reason I’ve been given was to avoid cyclic dependencies, but given zlib has no dependencies itself… Instead, what do we gain, if we actually add it to all the packages that do use it, you have proper reverse-dependency information, which can be used for instance by a much more sophisticated tinderbox to identify which packages need to be rebuilt when one changes.
At the same time, the correct depgraph will be used by Portage to properly order zlib before any other package that do use it is merged; this is quite useful when you broke your system and you need to rebuild everything. And it’s not all, the idea is that you only need to specify dependencies on system packages only for other packages possibly in the system set; the problem is: how can you be certain you’re not in the system set? If you start to consider that pambase can bring gnome in the system set, it’s not really easy, and it’s a moving target as well.
So I beg to differ regarding complexity: if you simply follow the rule if it uses foo, it depends on foo the complexity will be reduced over time rather than increased: you don’t have to check whether foo and your package are in system set or not. The only two packages that QA approves of not depending upon are the C library and the compiler: all the rest has to be depended upon properly.
And in respect of the already-noted bug with distutils eclass: the same problem exists for other eclasses like apache, webapp and java, that would add their own dependencies by default… but have an explicit way to disable the dependencies and the code or tie them to an USE flag. You know, that is not complexity; that is a properly-designed eclass.
I can never agree this any more. Some obviously useless packages are really unneeded for some certain systems and they should be allowed to purge. IMHO, system packages are not what are not necessary to describe as dependencies, or what should be kept in the system even they are only capturing diskspace and doing nothing else.What’s more, for pkgcore users, portage dependency problem is really annoying. Why should glibc needs portage just because old portage cannot master the installation? Many users already suggested that it should be modified as “!<portage-2.x.x.x” but=”” the=”” bug=”” is=”” still=”” open.=”” so=”” are=”” some=”” java=”” packages.=”” dependencies=”” are=”” something=”” really=”” needed=”” to=”” keep=”” the=”” programmes=”” working,=”” while=”” “!dependencies”=”” is=”” the=”” right=”” way=”” to=”” show=”” conflictions.=”” imho,=”” there=”” should=”” be=”” a=”” clear=”” and=”” meaningful=”” criteria=”” to=”” judge=”” what=”” is=”” a=”” dependency=”” and=”” what=”” is=”” a=”” system=”” package,=”” not=”” just=”” saying=”” “ooo=”” works=”” with=”” without=”” xxx”.=””>
What about dependencies for unpacking like app-arch/unzip? Does that mean we should also depend on app-arch/tar and app-arch/bzip2?
Well app-arch/unzip _has_ to be depended upon. As for tar and bzip2… most likely, but I’d like to see “my request implemented first”:https://bugs.gentoo.org/sho… (note that there are no new comments on that bug since May 2008).
You better get the devmanual fixed, the recruiters answers fixed and the developer community fixed for this effort. Good luck.
Excuse my naivety, but wouldn’t the ‘correct’ solution be to BDEPENDS build dependencies in the ebuilds, and have a build set containing the non-runtime system dependencies.A runtime embedded system could then be created in a chroot, and all the build dependencies quickly identified and removed for the install stage.Or am I missing something?
Doh, misread the difference between DEPENDS and RDEPENDS.So DEPENDS and RDEPENDS all need to be set correctly. But I I think that filtering the system set into system and build might be useful
Diego++;
Also libtool? I’ve been leaving it out with gcc and libc.:-/
I think autotools.eclass already brings it in, you should add it as RDEPEND when the package uses libltdl, though.Besides autotools regeneration libtool is not needed at build time.
Do you know whether a package you’re packaging uses sed or awk somewhere in the vast depths of its build system? Do you really want people to have find out and then check every single release for updates?
If I know it uses them, I add them, if I don’t, when somebody will complain it doesn’t work, I’ll add them, without appealing to “it’s in system set so I won’t add a depend on it”. It looks like an almost perfect solution to me.
I probably am biased, but maybe having all those many little command-line tools that might be needed as a separate dependency is not so great, maybe a posix-tools virtual or something like this that brings in all tools required by POSIX would be a good idea? (I admit I am not really sure if it is a good idea or not).
Sorry Diego, but whether you call bullshit or not, you’re simply wrong. The system set exists so we don’t have to worry about this crap. If you need to do a code audit to write a simple ebuild (that now has a list of twenty+ dependencies), that adds complexity.The whole point of the system set is to have a list of packages guaranteed to exist on every system. Adding these packages to nearly every ebuild in the tree is a wasted effort. And yes, it is an effort.I don’t worry about which of my packages might use basename in their build script, and if they need a DEP on coreutils. If the world worked like you describe then I would suddenly have to care. I would have to fix this oversight. I would have to check each of my packages to see if any of them use any utility coreutils provides. I would have to redo this any time coreutils added or removed a utility. This is a lot of effort. Now, of course, I’m exaggerating. No one would go through this kind of self-abuse. As you say, just add dependencies when someone complains they’re missing. But the thing is, no one would ever complain, because coreutils is in the system set, which means it’s installed on everyone’s system. The only people complaining will be those who actively enjoy self-abuse or have nothing better to do than annoy other people with more work they can do. So the dependency info for the majority of the tree will remain incomplete.The system set is not a moving target. It’s defined in /profiles/base/packages. If your package is not one of these, you’re not in the system set, no matter what @system happens to pull in. (Any dependency not in this list must be specified.)
Ryan I don’t expect that everyone goes to code audit his packages when adding them to the tree. But I do expect them to *not complain that $foo is in system set* if I ask them to depend on $foo, which is needed otherwise it won’t work!It would be all fine and dandy if the system list only contained packages that are _really_ part of the system, like coreutils, sed, gawk, basically what Reiman called above the POSIX set.Unfortunately, the system set lost this meaning a long time ago: it’s whatever is installed in stage3 and that is *not* a truly limited set. For instance zlib is not something that you should ignore dependencies on, nor is readline or other libraries in there. Or m4 and autotools.Just so you know, updating my vserver today produced this, after I explicitly merged the packages that revdep-rebuild rebuilt after a readline update:<typo:code>[binary R ] dev-db/sqlite-3.6.16 USE=”threadsafe -debug -doc -soundex -tcl” [binary U ] sys-libs/readline-6.0_p3 [5.2_p13][binary R ] dev-lang/ruby-1.8.6_p369 USE=”ssl -berkdb -debug -doc -emacs -examples -gdbm -ipv6 -rubytests -socks5 -threads -tk -xemacs” [binary R ] app-crypt/gnupg-1.4.9 USE=”readline zlib -bindist -bzip2 -curl -ecc -idea -ldap -nls (-selinux) -smartcard -static -usb” LINGUAS=”-ru” [binary R ] dev-db/postgresql-8.1.11 USE=”readline zlib -doc -kerberos -nls -pam -perl -pg-intdatetime -python (-selinux) -ssl -tcl -test -xml” [binary N ] sys-devel/bc-1.06.95 USE=”readline -libedit -static” </typo:code>What’s the problem? That sqlite uses readline, so if for any reason the emerge stopped before the merge of the new readline, I would have had a broken sqlite.
damns. yeah, you do seem to have a point there.
What about this:- split ‘system’ set to sets ‘system’ and ‘common-build’, where system contains packages needed to boot the minimal system and common-build contains all the junk needed to build packages (perl, awk, sed, …)- remove all other packages from the ‘system’ set (zlib, …)- portage build-depends on ‘common-build’ set that contains all the junk, so ebuilds can still use this junk in build-timeThis would be a good solution for embedded people, as the common-build set could be unmerged before deployment. Also, the ebuild complexity would not increase.