Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools
maillog: 20/05/2005-06:06:21(+0100): Ciaran McCreesh types On Thu, 19 May 2005 04:44:25 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: | http://www.firedrop.org.uk/devmanual/general-concepts/autotools/ Updated based upon the feedback, thanks guys. If someone who's relatively clueless about autotools could give it a read and let me know what is and isn't clear I'd appreciate it. That would be me. Notes: - typo? - The configure script is run to produce one or Makefile files from Makefile.in files. + The configure script is run to produce one or more Makefile files from Makefile.in files. - clarification AC_MSG_CHECKING(--enable-cscope argument) AC_ARG_ENABLE(cscope, [ --enable-cscope Include cscope interface.], [enable_cscope=$enableval], [enable_cscope=no]) AC_MSG_RESULT($enable_cscope) if test $enable_cscope = yes; then AC_DEFINE(FEAT_CSCOPE) fi 1 paragraph skipped Important: The third argument is used when an option is specified, and the fourth is used when an option is not specified. A common misconception is that the third is enable and the fourth is disable this is not the case. You may encounter packages that get this wrong. The phrase when an option is specified is a bit ambiguous, especially since it is later referred by the explanation of AC_ARG_WITH. I was not sure if option in this case means option as in --enable-foo=OPTION. I was confused, because one paragarph before the example you talk about --enable-foo and --disable-foo *switches* to ./configure. Maybe the above can be written as: The third argument is used when either --enable or --disable is specified, and the fourth is used when neither is specified. Or you could simply stick to using switches instead of options? - coloring %.1 : %.in @regex_cmd@ -e s,[EMAIL PROTECTED]@,$(VERSION),g $? $@ The first @ is span.Special and the second one is span.Constant. Good job by the way. -- () Georgi Georgiev () There is only one thing in the world worse () ()[EMAIL PROTECTED]() than being talked about, and that is not () () +81(90)2877-8845 () being talked about. -- Oscar Wilde () pgp8Phc1VyZhW.pgp Description: PGP signature
Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools
On Fri, 20 May 2005 15:06:12 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | - The configure script is run to produce one or Makefile files | from Makefile.in files. | + The configure script is run to produce | one or more Makefile files from Makefile.in files. Gah! I'm sure I'd already fixed that one... | The phrase when an option is specified is a bit ambiguous, | especially since it is later referred by the explanation of | AC_ARG_WITH. I was not sure if option in this case means option as | in --enable-foo=OPTION. I was confused, because one paragarph before | the example you talk about --enable-foo and --disable-foo *switches* | to ./configure. .. Important:: The third argument is used when a ``--enable`` or ``--disable`` switch to ``./configure`` is provided, and the fourth is used when such a switch is *not* passed. A common misconception is that the third is enable and the fourth is disable -- this is **not** the case. You may encounter packages that get this wrong. Does that sound any better? | - coloring | | %.1 : %.in | @regex_cmd@ -e s,[EMAIL PROTECTED]@,$(VERSION),g $? $@ | | The first @ is span.Special and the second one is span.Constant. Hrm, that's a vim thing (I'm using a vim script to do the highlighting at compile time, it's not manual). If someone enjoys pain they could have a go at making vim's automake highlighting smarter... Don't think I'm brave enough to touch that one myself. Thanks, -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp4NMEc6HETO.pgp Description: PGP signature
[gentoo-dev] Re: UPGRADE complete bugs.gentoo.org
Hello. Jeffrey Forman wrote: The upgrade for bugs.gentoo.org went exactly as I had planned for. Completed in under 20 minutes, which included this email. I've upgraded our Bugzilla from the old 2.18rc2 to 2.18.1. This fixes more security and code than I can even begin to mention. I have cleaned out a lot of the code and added in some nice features. Sorry to bother you, but I was wondering what ppl think about the Advanced Query and Step one: search for your bug. on the submittal form only searching open bugs. I don't believe this was the case before the upgrade, but i could just have noticed it now. Either way, having these search all bugs, open and closed, would seriously lessen the number of dupes IMO. especially on the submittal form, where there's no way to change the behaviour and no indication that only open bugs are being returned. for most users, that search is the only one they do (if they do one at all). even for people that do bother to do an actual query, the adv search screen is a nightmare behemoth of complexity for the avg user. defaults should be geared towards these types of people so they can get the most accurate information they can without needing to know what all the buttons do, and hopefully stop filing dupes. did i mention it would cut down on dupes? ;) --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools
On Fri, 20 May 2005 18:01:04 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | | %.1 : %.in | | @regex_cmd@ -e s,[EMAIL PROTECTED]@,$(VERSION),g $? $@ | | | | The first @ is span.Special and the second one is span.Constant. | | Hrm, that's a vim thing (I'm using a vim script to do the | highlighting at compile time, it's not manual). If someone enjoys | pain they could have a go at making vim's automake highlighting | smarter... Don't think I'm brave enough to touch that one myself. | | The 2html.vim that comes with vim seems to work fine here. Tried both | 7__ and 6.3. The HTML is ugly, but at least it's properly highlighted: | | http://gg3.net/~chutz/gentoo/highlight/ | | Of course, you need to set ft=automake, which is different than | ft=make. ;) That's only working because you're indenting using spaces rather than tabs. If you indent using tabs you'll get the mixed colouring. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpwdBL1vLriN.pgp Description: PGP signature
Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools
maillog: 20/05/2005-10:29:53(+0100): Ciaran McCreesh types On Fri, 20 May 2005 18:01:04 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | | %.1 : %.in | | @regex_cmd@ -e s,[EMAIL PROTECTED]@,$(VERSION),g $? $@ | | | | The first @ is span.Special and the second one is span.Constant. | | Hrm, that's a vim thing (I'm using a vim script to do the | highlighting at compile time, it's not manual). If someone enjoys | pain they could have a go at making vim's automake highlighting | smarter... Don't think I'm brave enough to touch that one myself. | | The 2html.vim that comes with vim seems to work fine here. Tried both | 7__ and 6.3. The HTML is ugly, but at least it's properly highlighted: | | http://gg3.net/~chutz/gentoo/highlight/ | | Of course, you need to set ft=automake, which is different than | ft=make. ;) That's only working because you're indenting using spaces rather than tabs. If you indent using tabs you'll get the mixed colouring. O, so true, so true... I am trying to redeem myself with the following. Care to give it a try? --- /usr/share/vim/vim70aa/syntax/automake.vim.old 2005-05-20 19:05:09.0 +0900 +++ /usr/share/vim/vim70aa/syntax/automake.vim 2005-05-20 19:07:05.0 +0900 @@ -43,6 +43,7 @@ syn region automakeMakeDString start=++ skip=+\\+ end=++ contains=makeIdent,automakeSubstitution syn region automakeMakeSString start=+'+ skip=+\\'+ end=+'+ contains=makeIdent,automakeSubstitution syn region automakeMakeBString start=+`+ skip=+\\`+ end=+`+ contains=makeIdent,makeSString,makeDString,makeNextLine,automakeSubstitution +syn region makeCommands start=;hs=s+1 start=^\t end=^[^\t#]me=e-1,re=e-1 end=^$ contained contains=makeCmdNextLine,makeSpecial,makeComment,makeIdent,makePreCondit,makeDefine,makeDString,makeSString,autoMakeSubst,automakeMakeError,automakeBadSubst nextgroup=makeCommandError Define the default highlighting. For version 5.7 and earlier: only when not done already -- /\ Georgi Georgiev /\ Be not anxious about what you have, but /\ \/[EMAIL PROTECTED]\/ about what you are. -- Pope St. Gregory I\/ /\ +81(90)2877-8845 /\ /\ pgpl8EQHZEjAs.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Jason Stubbs wrote:
snip
I intend that the package to be installed should not assume anything about
where its dependencies are and should query portage for them all.
Oh no, now many things get much clearer to me :(
But - aren't there many settings left over to the packages to decide,
at least to choose the package-defaults ?
Requiring ebuilds to have special handling for when their dependencies
are in the same ${PREFIX} and when in a different ${PREFIX} just seems
crazy to me.
Agreed.
You intend to use some portage-API in ebuilds which knows where and how
to look for dependencies, did i get this right ?
But having portage to behave differently seems crazy to me though.
If portage doesn't tell the packages what to build against, they'll go their
own merry way which would definitely make the binary packages mentioned below
impossible.
Disagreed - binary packages right now can only be shared between highly
identical machines...
It seems that there are two philosophies of how packages find their
dependencies:
1) The Gentoo-Linux one:
All the depency information comes from the package manager and is
passed to packages by commandline, skipping the whole
autoconf-intelligence.
pro:
+ The patching required for packages is less complex, most of the
time the autoconf-intelligence has to be disabled if there's a
commandline parameter missing for a particular feature.
contra:
- To get this work on different platforms, an autoconf alike
intelligence has to be re-implemented to portage and the ebuilds,
including access to provided/injected packages or to the
primary pkg mgr's database.
- External packages installed by hand into the primary prefix will not
be stored in the primary pkg mgr's database and therefore cannot
be seen by portage as the secondary mgr once portage could read it.
- There's always a rest of decicions left to the package's
autoconf-intelligence.
- This works for the primary package mgr, but would become
unmaintainable for secondary installations - which is your
legitimate fear.
- Different behaviour seems to be required within the ebuilds or
(through an API) portage if installed to / or prefix or ~.
2) The one necessary for secondary installation:
Let the packages decide from environment (PATH,PKG_CONFIG_PATH,...)
and filesystem where to find their dependencies, and the package
manager just has to prepare the environment variables and the
filesystem to let the autoconf intelligence work.
pro:
+ Many of the packages already do compile and run on several platforms,
by checking the environment and filesystem, and are shipped with the
autoconf-intelligence required for that.
This intelligence is used and therefore not needed in portage and
ebuilds.
+ This is what autoconf/libtool are created for.
+ If there are external packages installed by hand into the primary
prefix, they are normally recognized, because they appear on the
filesystem and in the environment.
+ When installing within a primary portage, this continues to work.
+ The pkg mgr does nearly the same commands as an administrator likes to
do by hand if she has no pkg mgr at hand:
./configure [--prefix=/my/prefix]
make
make install [DESTDIR=/tmp/inst]
without any more arguments ideally.
+ Seems to be much less need for ebuild/portage to behave differently if
installed to / or prefix or ~
contra:
- If the autoconf-intelligence does not work, there's more effort needed
to create the patches to get it work.
- There's always a rest of issues needed to be dealt with in some
ebuilds.
Portage itself does not predetermine which philosophy to use - it is to
the ebuild-dev to choose one - but maybe portage's full-support for the
former doesn't exist and isn't going to exist for a very long time, if
ever (to say it with ciaranm's words).
To me now, my real problem seems to be the philosophy established
in the ebuild-devs right now, could that be the case ?
Until portage supports other package formats, an equivalent of
package.provided would be used for this. However, this has nothing to do with
how ebuilds would find out where their dependencies are.
Agreed, but just to ensure unterstanding:
One thing is the dependency tree for the pkg mgr to install all the
prerequisites, the other is how packages then find those prerequisites,
right ?
7 Portage needs to be able to configured with one-way dependency
allowance between installed package databases. For example, ~ installed
packages are allowed to depend on / installed packages.
When installing a package into ~, a dependency install to / or prefix
becomes triggered or sth. like that, do you mean this ?
This is just silly, in my opinion. Home-support may have issues beyond
prefix-support, but most of them are the same. Why would you only want to
consider prefix-support and implement it if considering home-support might
Re: [gentoo-dev] Naming scheme confusion
On Monday 16 May 2005 15:04, Henrik Brix Andersen wrote: The current ebuild is orinoco-0.15_rc2-r2.ebuild, and the logical name for a CVS snapshot would, as I see it, be orinoco-0.15_rc2_pre20050516.ebuild, but mixing _rcX and _preY is not allowed by portage. in any case it should be _pY as your snapshot is newer than the current version. _p stands for patch level, _pre for prerelease. In case of cvs ebuilds patch levels are more appropriate as the new version is often not known. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpJx3HZxt37N.pgp Description: PGP signature
Re: [gentoo-dev] Naming scheme confusion
On Tuesday 17 May 2005 10:27, Marius Mauch wrote: Well, it's valid with portage-2.1, but not 2.0. Concerning that, how far are we from it being testable by the general developer population? Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpUaDXjWhOxK.pgp Description: PGP signature
Re: [gentoo-dev] Request for Permission
On Monday 16 May 2005 23:48, Drake Wyrm wrote: Rick Sivernell [EMAIL PROTECTED] wrote: I am operating a small IT service organization and I would like to put a link to Gentoo on my site. My ad: [snip] If there is a standard ad that you would prefer, I will use it. This is a service for my clients use and reference. If you allow my listing your site, please extend your permission. If I'm out of line here, somebody slap me. Not really. This request should of course be send to the foundation ;-), but that's not really a problem. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpT9DSFNotyD.pgp Description: PGP signature
Re: [gentoo-dev] Keywording, for the umpteenth time
On Fri, 2005-05-20 at 10:42 -0600, Jason Wever wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, let's review this again. If you cannot test a given ebuild on a given arch, then don't touch that arch's keyword (unless you need to remove it for broken dependencies). If you can test for a given arch and are not part of that arch team, please please please let the arch teams know that before you go around keywording things arbitrarily. It makes the baby Jesus cry when you don't and really isn't the greatest from a QA perspective either. Sorry folks this was my fault. I've sent my grovelling apology to the sparc team. Hopefully they'll accept my apologies and put my digressions down to me being a new dev. :-) Actually I did do fairly thorough testing / QA but I didn't tell the arch team before keywording (bad me!). In case anyone is interested; this is about the Haskell packages which I hope to get up to scratch on sparc (with the consent and approval of the sparc team in future!) Duncan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keywording, for the umpteenth time
On Friday 20 May 2005 02:53 pm, Duncan Coutts wrote: Sorry folks this was my fault. ah, good to know ... thought it might have been my binutils-2.16 ~sparc marking, but i guess that's somewhat sane since Weeve gave it a quick run and it seems to be OK thus far ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keywording, for the umpteenth time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 20 May 2005, Duncan Coutts wrote: Sorry folks this was my fault. I've sent my grovelling apology to the sparc team. Hopefully they'll accept my apologies and put my digressions down to me being a new dev. :-) You can only take some of the credit Duncan, but not all of it :) Every once and a while it seems a reminder such as this is needed as people tend to start playing with package keywords when they shouldn't be. It's kind of like guarding the cookie jar, you can't ever let your guard down, even if you cut off everyone else's hands. I try not to point fingers or name names since it's not something I like done to myself. I'd also like to think that this gives such guilty parties a better understanding of why the arch teams (and especially SPARC) can be so maniacal about this sometimes, in hopes that it will lessen and/or prevent this problem in the future. From my perspective, if a package maintainer asks for testing and the ability to keyword (i.e. Spanky asking me if it was OK to bump binutils to 2.16, to which I said yes) then that is fine. However adding or changing keywords in an ebuild for which you cannot test (regardless of how trivial the changes are or how portable the programming language of said package is supposed to be) is really where I'm looking at here. For some odd reason, trying to ensure QA (even in the nicest of fashions) seems to result in a majority of less than positive responses. Even recently I've had a developer get quite confrontational with me over email when I nicely asked him not to stabilize packages for which he could not test (even if the changes were supposedly trivial). History has shown that we cannot depend on assuming that trivial changes for me == works for you if we want to have some level of Q in QA. Cheers, - -- Jason Wever Gentoo/Sparc Co-Team Lead -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCjkP3dKvgdVioq28RAqw+AJ9yuqHTVZSsdnfyFt9PgJSm3jt+2QCdEjwE TS+flVWEr60GwuMEdWIqV/g= =xrIF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keywording, for the umpteenth time
Jason Wever wrote: snip From my perspective, if a package maintainer asks for testing and the ability to keyword (i.e. Spanky asking me if it was OK to bump binutils to 2.16, to which I said yes) then that is fine. However adding or changing keywords in an ebuild for which you cannot test (regardless of how trivial the changes are or how portable the programming language of said package is supposed to be) is really where I'm looking at here. Wouldn't it be better from a QA perspective to go back to the (really) old policy of dropping anything you can't test on. I know that puts more work on you guys, but this is only going to get worse as we get more devs. Wouldn't it be better to nip this in the bud now. Maybe broaden the arch teams by giving some devs access to remote boxes. --Or-- Get every dev access to all the supported arches (some of this could probably be done with emulators of some sort, qemu or somesuch). Make them test on every arch before they change any keywords. --Iggy For some odd reason, trying to ensure QA (even in the nicest of fashions) seems to result in a majority of less than positive responses. Even recently I've had a developer get quite confrontational with me over email when I nicely asked him not to stabilize packages for which he could not test (even if the changes were supposedly trivial). History has shown that we cannot depend on assuming that trivial changes for me == works for you if we want to have some level of Q in QA. Cheers, - -- Jason Wever Gentoo/Sparc Co-Team Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keywording, for the umpteenth time
On Fri, 20 May 2005 15:51:51 -0500 Brian Jackson [EMAIL PROTECTED] wrote: | Wouldn't it be better from a QA perspective to go back to the (really) | old policy of dropping anything you can't test on. I know that puts | more work on you guys, but this is only going to get worse as we get | more devs. Wouldn't it be better to nip this in the bud now. Maybe | broaden the arch teams by giving some devs access to remote boxes. Not really. Dropping to ~arch when bumping works well. Sure, ~arch does occasionally end up broken, but it's better than us lagging behind massively. There're too many packages and not enough people these days... The assumption is, if foo-1.2 works on, say, sparc, then foo-1.3 probably will too to the extent that we're happy for it to go to ~sparc. On the other hand, we're *not* confident enough in upstreams' abilities to always put out perfect releases that we're prepared to move things to stable without explicit testing. See, we *really* don't want arch to get broken. We'd rather ~arch didn't break either, of course, but taking the occasional hit there is acceptable if it lets us keep everything up to date. | Get every dev access to all the supported arches (some of this could | probably be done with emulators of some sort, qemu or somesuch). Make | them test on every arch before they change any keywords. Not gonna happen. Emulators don't cut it and won't find all the problems (but they will find a load of other bogus non-issues). Plus, from experience I'd say that at least half our devs wouldn't have a clue where to start when doing arch testing... Then there's the issue of most alt-archs having far higher QA standards than x86 anyway, and us not wanting to sink to what x86 considers acceptable for marking stable. From experience -- the current policy as it is now *works*, so long as everyone follows it. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp2HGtPZzQ6m.pgp Description: PGP signature
Re: [gentoo-dev] Keywording, for the umpteenth time
On Fri, 2005-05-20 at 22:22 +0100, Ciaran McCreesh wrote: Not gonna happen. Emulators don't cut it and won't find all the problems (but they will find a load of other bogus non-issues). Plus, from experience I'd say that at least half our devs wouldn't have a clue where to start when doing arch testing... Add this HOWTO arch test to your developer docs. Very nice by the way. Then there's the issue of most alt-archs having far higher QA standards than x86 anyway, and us not wanting to sink to what x86 considers acceptable for marking stable. From experience -- the current policy as it is now *works*, so long as everyone follows it. And as long as ciaranm, or someone from a non x86 arch bitches once a month here. -- Tom Wesley [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools
On Fri, 20 May 2005 19:11:13 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | O, so true, so true... | | I am trying to redeem myself with the following. Care to give it a | try? Pretty close, thanks. I think I'll adapt it a bit to define a cluster in make.vim and then add to that cluster in automake.vim rather than just overriding the entire rule. That way if make.vim is ever updated we'll either carry on working or get a nice visible patch failure rather than silent weirdness. Bug 93378 if you want to track it. I'll be doing new vim6 and 7 snapshots soon from the looks of things, so I'll include it then. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp7qHRs1zmHY.pgp Description: PGP signature
Re: [gentoo-dev] Keywording, for the umpteenth time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Cummings wrote: It's a nice idea (I know I recently opened negotiations up with the mips team for access so I could close some of my open bugs against them), but the two problems I can see with this are: remote access tends to mean you can't test any X related properly (shoot, I have a sparc sitting next to me headless, but being headless I never broach the gui related sparc stuff) You might like to try Xvfb, Xvnc, etc., perhaps over nomachine if your network connection isn't too quick and you actually want to see the app. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCjn4NXVaO67S1rtsRAnWNAKDC1NJACSqtPg8zoqHouZdSDAs3IQCfYgJa UwbAeXV9Lnckq0CBZAIBLwQ= =1jAq -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Friday 20 May 2005 21:30, Michael Haubenwallner wrote:
Jason Stubbs wrote:
snip
I intend that the package to be installed should not assume anything
about where its dependencies are and should query portage for them all.
Oh no, now many things get much clearer to me :(
But - aren't there many settings left over to the packages to decide,
at least to choose the package-defaults ?
Any package that does this is broken. There are a couple of cases where
there's no other choice because portage doesn't allow for anything else but
that will change.
Requiring ebuilds to have special handling for when their dependencies
are in the same ${PREFIX} and when in a different ${PREFIX} just seems
crazy to me.
Agreed.
You intend to use some portage-API in ebuilds which knows where and how
to look for dependencies, did i get this right ?
But having portage to behave differently seems crazy to me though.
I would fiercely disagree with implementing ${PREFIX} support without doing
major changes in portage to support it. There's enough hacks in portage
already.
If portage doesn't tell the packages what to build against, they'll go
their own merry way which would definitely make the binary packages
mentioned below impossible.
Disagreed - binary packages right now can only be shared between highly
identical machines...
In general, I do not be the case.
It seems that there are two philosophies of how packages find their
dependencies:
1) The Gentoo-Linux one:
All the depency information comes from the package manager and is
passed to packages by commandline, skipping the whole
autoconf-intelligence.
pro:
+ The patching required for packages is less complex, most of the
time the autoconf-intelligence has to be disabled if there's a
commandline parameter missing for a particular feature.
+ Portage is able to know what a package requires and can ensure system
consistency.
+ Binary packages are possible.
contra:
- To get this work on different platforms, an autoconf alike
intelligence has to be re-implemented to portage and the ebuilds,
including access to provided/injected packages or to the
primary pkg mgr's database.
Wrong. What do you think *DEPEND is if it's not autoconf alike intelligence?
- External packages installed by hand into the primary prefix will not
be stored in the primary pkg mgr's database and therefore cannot
be seen by portage as the secondary mgr once portage could read it.
No different to the current system. This is what package.provided is for.
- There's always a rest of decicions left to the package's
autoconf-intelligence.
Such as? I don't know if this is a pro or a con or what.
- This works for the primary package mgr, but would become
unmaintainable for secondary installations - which is your
legitimate fear.
Without it, there is no guarantee of system consistency and hence no reason
for adding support for it into portage at all. If you don't want portage to
maintain system consistency for you, why not just do ./configure; make; make
install ?
- Different behaviour seems to be required within the ebuilds or
(through an API) portage if installed to / or prefix or ~.
Different behaviour between prefix or ~ only. / is just another prefix. This
is definitely not a con of philosophy 1. It is a requirement regardless.
2) The one necessary for secondary installation:
Let the packages decide from environment (PATH,PKG_CONFIG_PATH,...)
and filesystem where to find their dependencies, and the package
manager just has to prepare the environment variables and the
filesystem to let the autoconf intelligence work.
necessary? I think not.
pro:
+ Many of the packages already do compile and run on several platforms,
by checking the environment and filesystem, and are shipped with the
autoconf-intelligence required for that.
This intelligence is used and therefore not needed in portage and
ebuilds.
Works the same for /, no? Tell me again what the point of portage is?
+ This is what autoconf/libtool are created for.
Do you use a new point to reiterate your last point just to make it look like
your way is better?
+ If there are external packages installed by hand into the primary
prefix, they are normally recognized, because they appear on the
filesystem and in the environment.
Woops. Exactly the same point again.
+ When installing within a primary portage, this continues to work.
And again. Except that here you're saying that system consistency should be
thrown out the window altogether. It seems to me like your concept of portage
is:
emerge() {
PKG=$1
tar zxf ${PKG}
cd ${PKG/.tar.gz/}
./configure
make make install
}
+ The pkg mgr does nearly the same commands as an administrator likes to
do by hand if she has no pkg mgr at hand:
./configure [--prefix=/my/prefix]
Re: [gentoo-dev] Wireless driver / firmware ebuilds wireless-tools
Stroller wrote: Hi, . far to long. Stroller. In summary and simple conclusion, yes you are wrong. So that makes 2 out of the 4 or 5 active Mobile herd devs who say you're wrong. brix is 100% correct. Let me give you an explaination The firmware itself does not depend on wireless-tools for operation. DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might want to use along with the package in question - it is for technical dependencies such as libraries and utilities. There ya go. Explained. In fact, you actually explained the logical reason in your e-mail, surprised you didn't notice it. But I'll highlight it for you. acx100 and rt2500 contain drivers. prism54 is a driver. ipw2200 is a driver. They depend on wireless-tools. The firmware, which in 2 of these cases are in seperate packages, do not depend on wireless-tools. And for a last example which I just thought of... ndiswrapper acts the sameway. Considering the Windows drivers are more of a firmware and ndiswrapper is the driver. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
