From: Vitaly Kushneriuk <vitaly@jungo.com>
To: gentoo-dev@gentoo.org
Subject: [gentoo-dev] New ideas, USE database, sandbox & more
Date: 03 Dec 2001 13:32:13 +0200 [thread overview]
Message-ID: <1007379134.13527.5.camel@uranus.u235.eyep.net> (raw)
In-Reply-To: <003f01c17bcd$ed380c30$6400a8c0@server>
On Mon, 2001-12-03 at 09:41, Sebastian Werner wrote:
> Hey,
>
> I like your idea. I have the same problems with the many variables I
> could set. Some other idea I think could be good is to store the data
> with gconf or something else (a binary registry - like windows but
> better).
>
> Sebastian Werner
I like the idea too, but I don't think we should use gconf.
This information should be stored in clear text for easy
inspection/editing.
Some more ideas:
Note before I start: I can participate in development of my proposals,
but I want to be sure that you guys like the ideas. Please comment...
1)Actualy used features should be stored ,so that if
I install a package which can use FEATURE1 and FEATURE2, but
only FEATURE1 is available(and used) at the build time, I'd like to be
notified when I install another package that provides FEATURE2, that
I can remerge the first package for additional functionality.
As all USES available during build are already stored in /var/db
We only need to add list of possible USES in .ebuild.
2)Long descriptions should be added.
3)emerge should search for package in category dirs. So that
"emerge gcc" as "emerge sys-devel/gcc"
4)ebuilds must be simplified! Most packages can be build by rpm macros
%setup
%configure
%make
%makeinstall
We should provide such macros for our builds and use them in the
default implementation for unpack/compile/install functions.
So that most ebuilds will contain only URL/DESCRIPTION etc.
5)Compile and install logs should be stored for future inspection.
Should be realy simple to implement. Just redirect sub shell to
"| tee <logfilename>. Or even "> logfilename" if emerge called with
--silent flag.
6)Why bother with the sendbox and not just compile and install nonroot?
Some packages will even refuse to be built by root. Take a look at
rpm build system. Any reasonably good srpm will compile as non root.
7)And while we at it, why not using rpm as underlying package system
with Portage metadata added to the rpm file. Yes, I know, rpm is
considered "evil" by many linux hackers alike. I don't see a real
reason why. If rpm complains about some dependency stuff, you can
allways run
"rpm --force --nodeps"
to make it look like just a tarball. Still there must be a reason why
it complains, so some action should be taken (i.e. other package
removed/recompiled etc), and that exectly what Portage can
take care of. And, btw, rpm config file protection is realy great.
( well, we can do the same in Portage, but why reinvent the wheel?)
And yes, I VERY like to type 'rpm -qf <filename>' to know
which package installed this file. While an average Gentoo admin knows
her system better then an admin using binary distribution, it's
impossible/impractical to know EVERY file on the system. And this is
only one of the many useful rpm queries I'm used to like. So here how
I see the integration:
* Compilation and installation are performed as usual
su'ed to some "build" user (see 6).
* All Portage metadata is "installed" into
<build_install_root>/var/db
No need for CONTENTS/CATEGORY/LICENSE/PROVIDE/RDEPEND
* src_files() function is called to generate rpm %files list.
auto_files() function called from default src_files() will
scan install root directory and prepend all files in /etc
with %conf, and all files in */doc/, */man/ or */info/ with
%doc. Well, actualy some configurable list can be used for config
directories.
If, for some package, this function fails for some file,
the package files() function can easily fix it by something like:
echo %defattr(-, bin, bin)
auto_files | grep -v 'myconfig' | grep -v devattr
echo %conf %attr(-, bin, wheel) /mydir/myconfig
I have auto_file implementation I used to build rpms
when I used RedHat.
* spec file is generated ( we allready have that )
and all the files packaged into rpm ( in future versions we even
can create rpm directly using rpmlib api )
* rpm package is installed by "rpm -Uvh"
This is the ONLY stage performed as root.
next prev parent reply other threads:[~2001-12-03 11:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-03 1:06 [gentoo-dev] USE database? Zach Forrest
2001-12-03 7:41 ` AW: " Sebastian Werner
2001-12-03 9:13 ` Geert Bevin
2001-12-03 10:02 ` AW: " Sebastian Werner
2001-12-03 10:12 ` Geert Bevin
2001-12-03 11:05 ` AW: " Sebastian Werner
2001-12-03 11:05 ` Geert Bevin
2001-12-03 11:26 ` AW: " Sebastian Werner
2001-12-03 11:32 ` Vitaly Kushneriuk [this message]
2001-12-03 11:48 ` [gentoo-dev] New ideas, USE database, sandbox & more Geert Bevin
2001-12-03 12:55 ` Vitaly Kushneriuk
2001-12-03 14:01 ` Joshua Pierre
2001-12-03 16:06 ` Vitaly Kushneriuk
2001-12-03 16:28 ` Daniel Robbins
2001-12-03 18:00 ` Vitaly Kushneriuk
2001-12-03 16:48 ` [gentoo-dev] USE database? Daniel Robbins
2001-12-06 6:01 ` Mikael Hallendal
2001-12-06 18:12 ` Zach Forrest
2001-12-06 20:38 ` Mikael Hallendal
2001-12-06 22:33 ` Zach Forrest
2001-12-06 23:40 ` Daniel Robbins
2001-12-06 23:52 ` Zach Forrest
2001-12-07 19:28 ` Sebastian Werner
2001-12-07 21:39 ` Daniel Robbins
2001-12-07 21:43 ` Geert Bevin
2001-12-08 1:44 ` Mikael Hallendal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1007379134.13527.5.camel@uranus.u235.eyep.net \
--to=vitaly@jungo.com \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox