Re: [gentoo-portage-dev] Non-root installs
On Mar 19, 2006, at 2:05 PM, tvali wrote: Many types of applications, like games, would be installed as normal user as well. Would it have any point to make portage user-installations into user space? There is a prefixed branch of portage that has this functionality. Its still in a heavy state of flux, and far from stable at this point, but the bulk of the grunt work has been done. You can grab a snapshot from here [1] and and the corresponding ebuild repo from here [2] Most of the people working on it can be found on the gentoo-alt mailing list and the #gentoo-alt IRC channel. --Kito [1] http://dev.gentoo.org/~kito/distfiles/portage-prefix-2.1.12.tar.bz2 [2] http://gentoo.osuosl.org/experimental/snapshots/portage-alt- prefix-latest.tar.bz2 -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Move PORTAGE_INST_UID and PORTAGE_INST_GID to make.globals?
On Mar 10, 2006, at 4:26 AM, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, What do people think about moving PORTAGE_INST_UID and PORTAGE_INST_GID to make.globals? Would the profiles not be a more logical place to set these? If not, can we twist the logic to make it so? :p --Kito -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Emanuele Giaquin (exg)
wt! =) On Mar 6, 2006, at 1:47 PM, Grobian wrote: At last... :) Welcome Emanuele! On 06-03-2006 20:41:28 +0100, [EMAIL PROTECTED] wrote: Hi all. Slightly late but never the less I'd like to introduce Emanuele Giaquinta (exg) who joined the team a few weeks ago. Emanuele will be working on Gentoo/OSX and ppc stuff when he's not making up weird potions :) Before joining Gentoo Emanuele has contributed to gentoo, rxvt- unicode and other free software/open source projects. Emanuele is a 23 year old student in computer science at the university of Catania, in Italy. Besides spending time on Gentoo he's fond of manga/anime, listening/playing music, poetry and mysticism. Welcome to the team Emanuele :) Regards, Bryan Østergaard -- Fabian Groffen Gentoo for Mac OS X Project -- gentoo-dev@gentoo.org mailing list --Kito -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Alfredo Tupone (Tupone)
On Mar 6, 2006, at 1:33 PM, [EMAIL PROTECTED] wrote: Hi all. Alfredo has joined the Gentoo team to help with the games herd. I'm sure he'll have a fun time testing all those games :) Alfredo writes about himself: I live in Rome, Italy. Italians, Italians, everywhere Italians! echo Kito | sed s/K/V/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Oct 5, 2005, at 3:57 PM, Ciaran McCreesh wrote:
On Wed, 5 Oct 2005 15:24:29 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| To head off the it's not going to work for vim-*, yah, you'll be
| boned and have to install duplicate vim-* into the global prefix.
| Bluntly, either you dive in and start wading through the problems
| (fixing them as you go), or you sit back listening to how it's never
| going to work (thus accomplishing nothing).
It can be made to work, so long as you don't
a) jump in without proper planning
Well, then lets plan, not flame.
b) assume that you'll not have to modify ebuilds
I don't think anyone(devs) has made this naive assumption have they?
and c)
demand that as soon as it's available, it works for all ebuilds.
I don't think anyone(devs) has made this naive demand have they?
So, lets address a) and c) since b) is a given.
My first question would be how to identify ebuilds that respect $
{prefix}?
A separate profile/keyword seems wrong.
ICANINSTALLTO was the best idea presented, but that implies it would
be a list of known working prefixes, which seems unrealistic. Maybe
it would be better to have portage error check that globally at the
load_config stage against a list of known stupid prefixes,
stupidprefixes=[/usr,/,/bin] etc. etc.
--Kito
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Oct 5, 2005, at 7:13 PM, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 18:40:46 -0500 Brian Harring [EMAIL PROTECTED] wrote: | It does in some places, it doesn't in others. It especially doesn't | for things that aren't normally found via PATH. It's a hell of a | mess. | | Examples? Of stuff in PATH? /bin/sh is assumed throughout to be a Bourne compatible shell (and SHELL and CONFIG_SHELL aren't universally honoured). uname, hostname and sed are called with hard paths (with various fallbacks) in several early on stages. Of stuff not in path? There's no standard and widely used way of digging up where libexec tools are. Its not like this is unchartered territory... off the top o' me head pkgsrc, DarwinPorts, openpkg, fink, written word, autopackage, MINE, and SamHain have all tackled this in one way or the other. All of these projects have their faults (duh? but then again so does portage and the ebuild tree) but a few of them have been quite successful despite their varying points of inherent silliness. --Kito -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Questions about CVS locations and GID...
On Oct 5, 2005, at 9:02 PM, Ciaran McCreesh wrote: On Wed, 5 Oct 2005 20:56:42 -0500 Kito [EMAIL PROTECTED] wrote: | Its not like this is unchartered territory... off the top o' | me head pkgsrc, DarwinPorts, openpkg, fink, written word, | autopackage, MINE, and SamHain have all tackled this in one way or | the other. All of these projects have their faults (duh? but then | again so does portage and the ebuild tree) but a few of them have | been quite successful despite their varying points of inherent | silliness. Sure. They work around it by having lots and lots of workaround code, not by solving the original problem. Most of the workaround code I see in the few of these I'm acquainted with is in the various bootstrap mechanisms, and the general deficiency of the underlying PM, i.e. no sane package versioning scheme (ports like python24, gcc3,gcc4, etc.), no globally defined 'build opts'(read: use flags), and nowhere to store platform specific knowledge (profiles), so all that crap ends up being stuffed directly in their portfiles. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-dev] Re: Gentoo alt-projects meeting 9/26 1900 UTC
Thanks for the feedback kids. Anyone who has any items they want
added, speak up!
Revised agenda list:
* Rollcall/Active members
* Elections/Nominations for project lead?
* Sub-project organization
* Project page content (tech notes, tasks data, etc)
* Alt-project roadmap
* Portage rewrite - alternate prefix installs(!), moving/adding
platform dependent code to loadable modules
* ${ARCH} usage, keywords and variables assignments
* Naming and categorization of alt-arch system packages
* Merging patches in the main tree
* Additional Repoman checks (cp -[a,d], /bin/false, etc.)
* Open Floor
--Kito
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Sep 16, 2005, at 4:50 PM, Mike Frysinger wrote: actually, going with say 'testing.mask' instead of '?arch' may be better ... reinforce the fact that this is a package-level issue rather than arch-specific I like that concept. A lot less communication overhead, and addresses most of the current problems AFAICT. --Kito -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
Greetings, On behalf of the g/fbsd and macos teams, I'd like to call a meeting for all members of the gentoo-alt projects (and anyone else who would like to attend) on Monday September 26 at 19:00 UTC. Items on the Agenda so far: * Naming and categorization of alt-arch system packages * Merging patches in the main tree * Additional Repoman checks (cp -[a,d], /bin/false, etc.) * Project page content (tech notes, tasks data, active devs, etc) * Portage rewrite - alternate prefix installs(!), moving/adding platform dependent code to loadable modules * Alt-project roadmap Flame-on. --Kito -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
I guess knowing where the meeting will be held might help attendance a little... #gentoo-alt it is! --Kito -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Aug 24, 2005, at 7:04 PM, Brian Harring wrote: Hola all. [...] So, fex, the following flags are rather desktop specific- alsa arts avi bitmap-fonts cups eds emboss (why the hell is European Molecular Biology Open Software Suite a profile default? Seems extremely specialized) encode fortran foomaticdb gnome gstreamer gtk gtk2 imlib kde mad mikmod motif mp3 mpeg ogg oggvorbis oss png qt quicktime sdl spell truetype truetype-fonts type1-fonts vorbis xml2 xmms When I did my first Gentoo install in the 1.4ish era, I was pretty shocked to see roughly this same insane list. I quickly learned about the -* trick, as the main thing that brought me to this distro was the minimalist factor. As you pointed out, -* is pretty ugly as it leaves the user with the task of recreating a sane default use list. [...] So yeah, subprofiles, reasons why not? Aside from the work involved, I see no reason to not use the cascades for what they seem to be made for. --Kito My slightly flamey 2 cents ~harring -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-osx] Package testing -- Automated initiative
On Aug 15, 2005, at 10:39 AM, Grobian wrote: Chris Gianelloni wrote: By the way, I am working to get catalyst running on OSX, so version 2.0 will definite suit your needs when it is released. Very cool. I had 1.x nearly working a while back...haven't looked at 2.0 yet. If you need help on OSX specific things, be sure to contact us... Indeed. -- Fabian Groffen eBuild Porting Gentoo for Mac OS X -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-osx] Package testing -- Automated initiative
On Aug 15, 2005, at 12:07 PM, Chris Gianelloni wrote: I managed to get it to work once I made some dirty hacks to account for uname being different, and removing dependencies on /proc... once inside the chroot, it's Linux anyway, so none of the BSDism's are an issue. Ok, let me know if you want/need an account on our little dev machine for testing anything. Note: I am talking about being able to *run* catalyst on OSX, not build OSX targets with catalyst. I'm sure that support would be something we added later as the project matured. Yeah of course, I wasn't expecting you to work miracles ;) For the package testing stuff, I should have a stage1 tarball done in the coming weeks(months?) that could be used to do proper chroot'd builds for Darwin/OS X. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-osx] Package testing -- Automated initiative
the error email
notification service.
Compile testing a package is supposed to be a thorough test that
tries all possible combinations of the package's USE flags. As
this might be somewhat endless as some packages are rather big and
have zillions of USE flags, it may be necessary to have a special
don't do it file.
Since all dependencies were put at the front of the queue, there
should normally be no dependencies that the package pulls.
If compilation fails for a certain USE-flag combination this is
reported by sending out an email, and compilation of the next USE-
flag combination is attempted.
When everything goes fine, no email notification is being sent
out. A convenient log structure would, however, make it possible
to see which packages and USE-flag combinations successfully passed
through. Providing this log via a web-page would be a useful
thing. Again backing this with a DBMS to allow easy searching,
versioning and stuff is considered to be overhead, though crafting
logs in SQL's INSERT INTO format might enable another machine to
display the output data. Perhaps the communication methods needs a
section on itself.
Recap and Conclusion
By setting up a testing system, it is possible to greatly improve
the Quality of Service of the portage tree for an architecture by
exhaustive testing of both packages already in there, as well as
packages added or modified. Automated testing should not release
developers from testing themselves, but should help in pointing out
problems that may arise on moving grounds such as portage where
packages are constantly updated and dependencies might get broken.
ToDo
- Not only check dependencies of the respective package, but also
consider packages that depend on the respective package, thus
rebuilding all packages that depend on the package to check if
anything is broken by the update.
- Is there a gleptomaniac in the room? This would be useful for
x86 also, of course. In that case it may be necessary to make sure
the packages are split over multiple machines.
- The message system needs more customisation options, especially
backing things by a DBMS would allow for many nice bugzilla-like
preferences for email generation as well as web-based versioned
info/report pages
- To make the system even bigger, a central DBMS powered server
might take a leading role and ... {editor note: wait, stop it right
now, you're going too fast right now}
By The Way
==
- Kito offers his lil' chico as machine for this automated testing
initiative.
- Comments are welcome, as well as expressions of worry on my
mental state.
- Implementation of described system will need some better
specified system and needs some coding (the dirty work) in some
language...
--
Fabian Groffen
eBuild Porting
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Valid Profiles
On Jul 31, 2005, at 9:11 AM, Chris Gianelloni wrote: I especially need to know which profiles are valid for projects like embedded, hardened, and *bsd. Here is the state of macos profiles: Valid: default-darwin/ - macos/10.3 - macos/10.4 - macos/progressive Deprecated: default-macos/* default-macos-10.3/ default-macos-10.4/ Thanks, -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] ppc-macos dev machine online
Hi Kids, I have a lowly 500MhzG4 with 768MB Ram running OS X 10.4.2 and portage online in case anyone wants a shell for testing, breaking, or seeing why the macos team does some of the wacky things that they do...if you've never logged into a Darwin machine, don't be shy, the box is there to be abused. Reply off-list and I'll send you address and login. Regards, Kito -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [G/FBSD] /usr/lib/charset.alias
On Jul 15, 2005, at 7:45 PM, Mike Frysinger wrote: On Friday 15 July 2005 08:33 pm, Diego 'Flameeyes' Pettenò wrote: On Gentoo/FreeBSD and probably every other system using dev-util/ libiconv instead of the glibc-provided one creates the /usr/lib/ charset.alias file. Unfortunately this gets conflict over different packages. Exact same situation with Darwin/OS X... i thought the packages that create that file do so because they were utilizing some bundled crap ... regardless, i think this should be done on a global scale rather than per-package ... why not add some bashrc-foo to your profile ? Globally would definitely be better IMO. But how would bash-fu in a profile prevent a collision during a merge? can i get access to a fbsd box so i can test some of this crap ? i'd like to investigate sed/e2fsprogs and why it installs those files ... -mike -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] make and wrappers
On Jul 11, 2005, at 7:32 AM, Henrik Brix Andersen wrote: On Mon, 2005-07-11 at 14:20 +0200, Diego 'Flameeyes' Pettenò wrote: Let's see: we already have an emake script, but using it for make install is a no-go because it uses -jX from make.conf and that's not good. A solution can be to improve emake wrapper to check if install is in its commandline, in which case it can automatically add a -j1 to be safe. What is the problem with using -jX for `make install`? THink about what happens in most `make install` phases, files get put in their DESTROOT, and many times permissions are set etc. when its done in parallel the chances of the makefile trying to operate on non- existent targets is quite high, and things start to explode. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
I'll even top post this one :P Take it back to the thread flameeyes started about this originally pretty please, with sugar on top. On Jul 9, 2005, at 9:10 AM, Martin Schlemmer wrote: On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote: On Saturday 09 July 2005 15:05, Martin Schlemmer wrote: Ditto - point being, is that if you want the agony of per-ebuild hacks, be my guest, but do not expect the rest to hold your hand. It's not a matter of per-ebuild hack. Let me explain for example: for a bit of time we had make - gmake alias on g/fbsd profiles, but emake still called plain make (bsdmake). That was fine for most of the cases, gawk was the first one failing because it uess $(RM) which on gmake is an internal but it's not in other makes. The good solution was to fix the configure.in (or .ac i don't remember) to make sure that RM variable was set. That was discarded and we needed to let emake call gmake. The problem of make/gmake is minimal, just a few corner cases, but I don't really like have to use alias make='gmake' in profiles. Could do a make wrapper similar to the emake one, that just stips /usr/$(get_libdir)/portage/bin from PATH, and then run $MAKE. Then bsd will only need to add MAKE=gmake to its profile, and change it to MAKE=make or whatever for the bsd only stuff ? (as I assume you already have to do that for emake ...) Anyhow, just a suggestion. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
On Jul 7, 2005, at 6:56 AM, John Myers wrote: On Tuesday 05 July 2005 02:39, Martin Schlemmer wrote: Also as already asked, what about the chicken egg issue ... (think tar needing tar, or gzip needing gzip to unpack)? The stages could come primed with the data that the packages on them are already installed. This is what I've been doing with the experimental Darwin stages as nearly every basesystem package has circular deps... Kito -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] EBUILD_FORMAT support
On Jul 6, 2005, at 8:01 PM, Nathan L. Adams wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Wegener wrote: On Wed, Jul 06, 2005 at 08:41:43PM -0400, Mike Frysinger wrote: On Wednesday 06 July 2005 08:20 pm, Sven Wegener wrote: We would like to introduce a new ebuild variable named EBUILD_FORMAT, seems like the name is much longer than it needs to be ... what's wrong with say 'EVER' ? It's fine too. EBUILD_FORMAT was just the name that fell in #gentoo-portage once we discussed about it. Sven EVER looks like the english word 'ever'; what does it stand for? EBUILD VERSION? If so, how about EVERSION? Since when was variable name length a problem? Go with whatever best describes the variable and is easy to figure out. Why not follow that logic through and use something like EBUILD_API ? the term VERSION implies release version which of course may not be tied to API changes... Kito Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzH772QTTR4CNEQARAlimAJ0Yh80KpXqc0yZv6Gli+KqpWaKBxQCfU6pR 2WqrKs4MfY+RCgpoFxZKD8Q= =5nzV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
On Jul 1, 2005, at 5:59 PM, Drake Wyrm wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
Currently, we pretty much leave out the big dogs of build depends
from
ebuilds- basically we rely on the profile to require a suitable
toolchain. Couple of issues with this though-
so what you're proposing is that we add binutils/gcc/glibc to
every package
that compiles something
Can you compile without binutils/gcc/glibc? No? Then you need it.
make to every package that uses make,
Again, if you depend on make, then DEPEND on make.
sed/grep/bash/coreutils to every package which runs configure
That's quite an interesting case. Yes, those should be in DEPEND,
but it
might be prudent to create an appropriate shortcut instead of
explicitly
adding each of those.
Three possibilities come to mind.
0) For ebuilds which use the standard GNU autoconf-generated configure
script, a standard set of tools could be added to DEPEND from a
standard variable.
DEPEND=${ac-configure} dev-libs/libwombat app-misc/
imanotherdep
where ${ac-configure} expands to everything that runs in yer
typical
configure script.
1) Use the eclasses. Right before inheriting eutils, provide a
token to
tell eutils to add some appropriate DEPEND tokens.
ac-configure=yup
inherit eutils
Many of the eclasses add a few DEPEND tokens. Use the standard
eclass(es) to add the standard DEPENDs.
2) Well, maybe cramming this into eutils isn't such a hot idea, but
creating an eclass for the purpose of adding the generic
dependencies
would work better.
edeps=configure make c-tools
inherit edeps
tar/gzip/bzip2 to every package which has a gzipped/bzipped
tarball in
SRC_URI ?
Now this could _definitely_ play into suggestion (2) above. Have the
edeps eclass check the SRC_URI and add the appropriate unpacking
packages.
edeps=make
SRC_URI=http://www.wombats.com/i_need_tar_and_bzip2.tar.bz2;
inherit edeps
Whee.
rant class=flame
I know this will be shot down, as it has been shot down each time
in the
past that somebody has suggested it. I wish it were not the case.
Almost
every ebuild in the tree fails to completely and accurately reflect
its
dependencies. The fact that this is somehow a technical decision leads
me to suspect that more of Portage is also horribly broken.
/rant
Well, {humans,monkeys,ebuild maintainers} can't be trusted to
accurately track a packages dependencies, be it build or runtime. The
way some other build systems deal with this is keeping a table
mapping files to packages, and simply monitoring every file touched
during compilation and runtime to generate deps.
Accurate deps should be a goal for the tree, a long term one
obviously...
Kito
--
Batou: Hey, Major... You ever hear of human rights?
Kusanagi: I understand the concept, but I've never seen it in action.
--Ghost in the Shell
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Initiation rites: sys-auth
On Jun 28, 2005, at 5:03 PM, Diego 'Flameeyes' Pettenò wrote: Ok as I was waiting for Azarah approval after Robbat's one here we are: [23:49] Flameeyes az, it was kito :P i'm just waiting for your opinion about sys-auth [23:50] az i cant see that anybody ever waited for my approval to do anything, but since it makes you feel all tingly and good inside, it sounds ok, just dont make me beat you by asking me to help move thing And now we are. Before starting doing something, I think it's better identifying all the packages we should moved. app-admin/pam_dotfile app-crypt/pam_krb5 app-crypt/pam_ssh net-libs/pam_ldap net-misc/pam_smb sys-apps/pam-login sys-libs/pam sys-libs/pam_mysql sys-libs/pam_passwdqc sys-libs/pam_pwdfile sys-libs/pam_require sys-libs/pam_ssh_agent sys-libs/pam_usb [and sys-libs/openpam sys-libs/freebsd-pam-modules which are g/fbsd specific] net-libs/nss_ldap sys-libs/libnss-mysql sys-libs/libnss-pgsql sys-libs/nss-db sys-libs/nss-mysql (why we have two?) sys-apps/shadow maybe: net-libs/courier-authlib And maybe also kerberos should be moved there as it's authentication? Yeah, I would add to the list: app-crypt/heimdal -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] root:root and fbsd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 22, 2005, at 4:20 AM, Diego 'Flameeyes' Pettenò wrote:
On Sunday 22 May 2005 11:06, Ciaran McCreesh wrote:
get_root_group() {
That should do, so in ebuilds chown -R root;$(get_root_group)
blablah.
For me is ok for G/FBSD.
Now, if someone from G/OSX or G/Darwin can tell me how they manage
that, we
can be happy for all /alt archs :P
Add the extra conditional for userland_Darwin and that should be good
for all the Gentoo redheaded step-children.
--
Diego Flameeyes Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
http://dev.gentoo.org/~flameeyes/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFCkJ9qJ0rMK/3OwgsRAvdxAJ9W7Bb1RmU3qUsZpRQEJL+dvjUWmQCdEj2X
WU/sF1HZur3JnRFZ8eAqjDA=
=yF9D
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 7, 2005, at 9:49 AM, Ciaran McCreesh wrote: On Sat, 7 May 2005 02:08:17 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Re: changes, yes, things will need changes, and again, as stated | thrice, those who want the changes are the ones who are stuck doing | said changes. In other words, the actual work required to | cleanse/correct the tree isn't getting dumped on ebuild devs as a | whole. Isn't going to work. A lot of these changes need package-specific knowledge that most people just don't have. If a dev doesn't have adequate knowledge for a particular package he shouldn't be fscking with it in the first place. So there said package can sit, having only the ability to install to / just like it always has until someone with interest/need/knowledge comes along and takes care of it. All the points you are making sound like the result of too much crisis management, progress shouldn't be impeded by fear of work or change. | In other words, you would be wise to snipe the suggested changes to | writing an ebuild, rather then dragging out example after example of | possible required changes to the tree. The examples you're dragging | out basically come down to making sure the ebuild is 'correct' for the | package. I can just as quickly drag out example after example of | potential mistakes ebuild devs can make _now_. No, they're a demonstration of why the GLEP in its current form is inadequate. I'll carry on pulling up further examples until you realise that it's not just a minor issue, it's a huge problem that needs a big change to the GLEP. How about suggesting what that big change would be? | Remember that gleps go through several rounds of | discussion, I'd like to see this round keep moving rather then get | stuck in the mud. The reason that this thing was written up as a GLEP was because the author was trying to bypass the discussion and get around having to fix various flaws that had been pointed out previously. | Could you break it down to if I'm going into home, I need xyz at the | home level rather then global/usr ? Hrm. Being able to say I need xyz installed globally, and abc installed either globally or at home level would work if and only if there was a way of finding out where abc and xyz had been installed. Hmmm, what about a possible extension to the world file or a create a new file to store metadata such as the package installation prefix. Kito -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCfN9mJ0rMK/3OwgsRAkQ4AJsFdsnck7jScHUDjarT3zO/+f0aCgCdGxyR O8+F1FVJNGQSAO5peV9/qhk= =4kQf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] eclectic-0.9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Very cool. Good work gentlemen. On May 7, 2005, at 4:37 PM, Ciaran McCreesh wrote: On Sat, 07 May 2005 22:37:22 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: | During the last few months, ciaranm, ka0ttic, slarti and me have been | working on eclectic [1], a modular administration and configuration | framework for Gentoo. Eclectic is completely written in bash and | unifies different tasks in one tool with a consistent user interfaces. Might as well post a sample module... This one's the kernel symlink manager thingie, which I wrote mainly as a test / demo thing but it can be vaguely useful too: http://svn.berlios.de/viewcvs/*checkout*/eclectic/trunk/modules/ kernel.eclectic Note the ebuild-like format that should be nice and easy for everyone to get their heads around. So what's this like from a user perspective? [EMAIL PROTECTED] ~ 0 2.30 $ eclectic kernel Usage: eclectic kernel action options Standard actions: help Display help text usage Display usage information version Display version information Extra actions: list List available kernel symlink targets set Set a new kernel symlink target show Show the current kernel symlink [EMAIL PROTECTED] ~ 0 2.30 $ eclectic kernel show Current kernel symlink: linux-2.6.12-rc1 [EMAIL PROTECTED] ~ 0 2.10 $ eclectic kernel list Available kernel symlink targets: [1] linux-2.6.10 [2] linux-2.6.11 [3] linux-2.6.11-rc5 [4] linux-2.6.12-rc1 [EMAIL PROTECTED] ~ 0 2.01 $ sudo eclectic kernel set 1 [EMAIL PROTECTED] ~ 0 2.01 $ eclectic kernel show Current kernel symlink: linux-2.6.10 It's all in colour, of course. But wait, it gets sneakier. Say we install a kernel-config symlink to eclectic. Then this will also work: [EMAIL PROTECTED] ~ 0 1.50 $ kernel-config list Available kernel symlink targets: [1] linux-2.6.10 [2] linux-2.6.11 [3] linux-2.6.11-rc5 [4] linux-2.6.12-rc1 I added this sneaky little hack in that checks the binary name, and if it's foo-config or foo-update, it treats it as eclectic foo [...]. So you don't even get to whine about the stupid name :) By the way, this could also implement GLEP 24 (consistent tool naming). See, if you run eclectic with no arguments: [EMAIL PROTECTED] ~ 0 1.36 $ eclectic Usage: eclectic module name options Built-in modules: help Display a help message list-modules Find and display available modules usage Display a usage message version Display version information Extra modules: bashcomp Manage contributed bash-completion scripts blas Manage installed BLAS implementations. kernelManage the /usr/src/linux symlink lapackManage installed LAPACK implementations. mailerManage the mailwrapper profiles in /etc/mail profile Manage the /etc/make.profile symlink Automagically generated list of all the modules available. *shrug* it's probably full of bugs still. | There is a both a developer guide and a user guide as RST shipped with | the source. Rendered versions here for the lazy: http://dev.gentoo.org/~ciaranm/tmp/eclectic/ | * What do we need to accomplish to get the status of an Official |Gentoo Project ? Is a manager voting necessary ? I'm staying out of this one... Oh, we have an IRC channel if you have development questions. You can figure out the name easily enough :) -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCfUKiJ0rMK/3OwgsRApNMAKChukknZzvb0B/hbmigWph3/d5aiwCeKWl1 M/mVz6D7rR/+KMXNJu23myY= =AXv5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE_EXPAND additions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 13, 2005, at 1:57 PM, Stephen Bennett wrote: On Wed, 2005-04-13 at 20:48 +0900, Jason Stubbs wrote: Anyway, any objections against moving the current USE_EXPAND out of make.globals and into base's make.defaults? Those using =2.0.50* won't get any additions (how it is now anyway) and anybody using a stacked profile (which requires =2.0.51) will get whatever is in make.globals overwritten with whatever is in make.defaults. Sounds good to me. Waiting on new portage releases for stuff we want to use in ebuilds kinda sucks, so (up to a point) the more we can move into profiles the better, as far as I'm concerned. Agreed. -- gentoo-dev@gentoo.org mailing list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCXWtmJ0rMK/3OwgsRAjOCAJ0UpDEVomjnctPEa5mtza+MYUZi3ACfagTV YxaEZaaVpB7TUz3O1IjeLv8= =BePN -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
