Most Wanted Portage Feature?

dek · l33t Joined: 16 May 2002 Posts: 657 Location: Germany

Different output for multislotted ebuilds in pretend mode.

Example: I have gimp-1.2.5 and gimp-1.3.19 installed. This is what i get on a "emerge -pu gimp":

lanius · Retired Dev Joined: 08 Dec 2002 Posts: 160

scriptkiddie · l33t Joined: 30 Mar 2003 Posts: 955

MySQL note... I was just meaning database, I just stated mysql because most people know what that is...

Postgres would be much faster than sql, and if you really wanted to push your limits you could have it use oracle

TGL · Posted: Tue Sep 16, 2003 11:02 pm Post subject:

In no particular order:

* reverse dependencies: not for unmerging kde (I don't really care about this case, qpkg+bash is okay), but for safety of the upgrades (portage should check that it won't break anything when it upgrades). And dependencies should also takes USE flags into account: sometimes you don't only need >=foo/bar-1.0, but ">=foo/bar-1.0 built with xxx and yyy support" (see bug #25085 for an example of the need).

* correct modules packages management: currently, if you use module like alsa-drivers and switch between several kernels, emerging the modules for one will uninstall the modules the others. That's crazy. See bug #24990 for a possible workaround.

* rewritten and documented code: Genone, you're so right on this... Portage code could be splitted in at least 10 times more classes that there is currently. Is a rewritting started, or planed?

* better use of slots: update in slots is really needed, for instance for revdep-rebuild to be 100% functional, to keep multiple versions all up-to-date, etc. (see bug #4698 and bug #22161). Also, a more strict "what, when, and how to slot" policy for devs is needed. No offence here, but slots are often badly used (see bug #26460 for an example). And also portage tools to help in that direction (see for instance two things I've suggested in this mail and bug #27965). Explicit slot in version would also be interresting ("emerge gimp:1.2" to emerge the latest slot 1.2 gimp).

* "emerge -u" levels: an idea which is close to the security update. In short, each ebuilds would declare what are the closest previous version from which he differs on a given level of improvement (let say "security" level would be 4, "major feature" 3, "minor feature" 2 and "cosmetic improvements" 1). Then, an "emerge -u -3" would only apply updates on packages for which there have been major feature updates or security updates.

* download/compile parallelism: well, you all know what I mean.

* multiple categories for packages: I don't like the current repository organisation. Package should be shared across several categories, and categories should be hierarchized. Technicaly, there are many approach to this, from text files with a few more info and some cache computation to the file sytem approac, and without forgetting the db approach. One of the numeous discussions on this topic is here.

* cryptographic signature of Manifests: you all know what I mean: defense against compromised rsync mirrors. See for instance bug #6356.

* ACCEPT_LICENSES option: this would be an optionnal feature for people who want, for instance, a 100% GPL compatible system (may be useful if yuo want to distribute a custom livecd built from gentoo, etc.). They would list the licenses they accept in this variable, and emerge would then refuse to install packages that are under different ones. (You could force it on command line exactly like you do for USE flags). Not hard to implement (I'm seriously thinking to do it), but I'm not sure the semantics of the LICENSE field in ebuilds is well defined (is the pipe a "or", a "and", etc.)

* library compatibility checker: when you compile a program, it usually load libfoo.1.0.so which is a symlink to libfoo.1.0.7.so for instance. But this is not always true, and sometimes programs link against libfoo.1.0.7.so and are then broken if libfoo is updated to 1.0.8. My idea is to run "ldd" on all binaries when they are merged, and to maintain a lib dependencies db based on that (libfoo.1.0.so is needed by xxx-3.6 and yyy-4.2, libfoo-1.0.7.so by zzz.0.0.8, etc.). When a library file is removed (during a clean after an update), portage would search this db to see if there are package to recompile so that they link against the new version. This would be a kind of incremental revdep-rebuild.

And I think it will be enough for near futur

EDIT: forgot an also important one:

portage targets for network administration: the goal would be, for people who have a network including old slow computers, or many identical ones, etc, to be able to emerge something from a server to some targets machines. This machine would may not have a compiler, and would not have portage repository or db. All the portage work (cross compil if archs differs, dependencies management, etc) would be done on the server, which would know its targets using several portage configurations and databases. This as been discussed last month in this thread.

EDIT-2: yet another forgoten one:

sticky variables: This feature would make portage reuse the same variables (cflags, use flags, accept_keywords, etc.) on updates than those used at install time. Imagine you want an ~x86 Gimp compiled with more agressive optimisations than your default ones, you wouldn't need to specify them on each update. Very useful in many cases. See bug #3252.

scriptkiddie · l33t Joined: 30 Mar 2003 Posts: 955

TGL · Posted: Tue Sep 16, 2003 11:15 pm Post subject:

Genone · Posted: Wed Sep 17, 2003 12:08 am Post subject:

TGL · Posted: Wed Sep 17, 2003 12:53 am Post subject:

zez · Posted: Wed Sep 17, 2003 1:45 am Post subject:

IvanHoe · l33t Joined: 05 Oct 2002 Posts: 658

I would like to have a graphical tool that shows all packages in a hierarchical tree view of dependancies so I can see the big picture and make informed decisions about what stays and what goes.

scriptkiddie · l33t Joined: 30 Mar 2003 Posts: 955

are you talking about a GUI where you can just run through and look at the entire tree and then see depencies and such?

If so, go here:
http://sourceforge.net/search/
search for 'portage'

Check out some of the GUI's and see which ones have the stuff to your liking

Koon · Retired Dev Joined: 10 Dec 2002 Posts: 518

Genone · Posted: Tue Sep 23, 2003 10:48 am Post subject:

EvilTwinSkippy · Posted: Sat Oct 04, 2003 10:57 pm Post subject: DB Backends

I've been reading a bunch of posts about using MySQL as a backend. That would be WAY overkill. A better approach would be Sqlite. It's a file-base SQL engine that is designed for embedded apps. I use it for various system maintenence tasks. (And it's already in the portage tree, and it already has python bindings.)
_________________
I've found that people will take what you say more seriously if you tell them Ben Franklin said it first.

slais-sysweb · Apprentice Joined: 14 Jun 2002 Posts: 221 Location: London

thrasher6670 · Posted: Sat Oct 04, 2003 11:16 pm Post subject:

TheCoop · Posted: Sun Oct 05, 2003 7:46 am Post subject: Re: DB Backends

Jyrinx · Posted: Tue Oct 07, 2003 6:05 am Post subject: Per-package USE ... PLEASE ...

This is what I'd LOVE to see:

There would be an /etc/make.conf.d directory, having for each Portage category a subdirectory, having for each package a file. For instance, I'm itching for an /etc/make.conf.d/media-video/totem file. In this file, I'd put one line: "USE=-gstreamer". Then I'd get the xine Totem, but the gstreamer RhythmBox. Similarly, packages might get [un]masked or [un]marked unstable this way. Now "emerge -u world" will do what I want with no fussing, and I don't have to emerge --oneshot or any such.

Seems to me it'd be semantically simpler than sticky variables (which would invite unintended consequences) while accomplishing the same thing (albeit slightly less conveniently - which I'd say is good, so that command-line USE flags can still be for temporary tinkering, just as they can be now).

Genone

Jyrinx

Genone · Posted: Wed Oct 08, 2003 12:58 am Post subject:

Per package USE flags and KEYWORDS are coming (in fact I'm one the devs who's working on the patch for it), but not a per-package make.conf as you suggested. If you look at the bug I mentioned you'll see what I'm talking about.
If you really want this feature now use my patchset (see sig), it contains the package.use and package.keywords patch as well as several others, but it's an experimental version, so prepare for bugs.

thrasher6670 · Posted: Wed Oct 08, 2003 1:03 am Post subject:

Genone · Posted: Wed Oct 08, 2003 1:09 am Post subject:

It only affects portage itself, not the tree.

stonent · Veteran Joined: 07 Aug 2003 Posts: 1139 Location: Texas

Going back to the guestimated build times or units, maybe provide a feature in the make.conf file to send back build information so that build times could be estimated for your arch. Bash units are interesting but bash changes over time, we would need something a little more static. I'd even be interested to see overal portage statistics such as most popular packages, or even an option to upload an error report based on a failed build. Then package maintainers could see how well their ebuild is doing in the wild.
_________________
Inspiron 4100 & Sun UltraAXe
Portage on Solaris|Dell Laptop Hacks
The way you feel about organized religion is the same way I feel about organized socialism.

Jyrinx · Posted: Wed Oct 08, 2003 2:40 am Post subject: