Re: [gentoo-portage-dev] [Bug 44796] Per package environment variables
On Friday 04 November 2005 04:30, Thomas de Grenier de Latour wrote:
On Fri, 4 Nov 2005 01:19:35 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
package.env would be a list of atom file [file ...]
...
With a couple of small modifications to emerge to check FEATURES
for buildpkg after the call to setcpv() is done rather than
doing it once globally, this would also cover TGL's BUILD_PKGS
addition too.
Not if env files are only selectable by strict depatoms. I mean,
sure this syntax is perfect for *DEPEND strings, and is fine for
package.{use,mask,unmask} (although the randomness of
best_match_to_list() is rather annoying). But for package.keywords,
it is already sub-optimal imho (i run ~arch so i don't care
much, but for instance i often see people on forums who list
some whole categories there), and it would be too for the generic
package.env. For instance, people who develop gnome stuffs might
want to use the debug env for gnome-*/* packages. As for
the buildpkg FEATURES flag, it would be a real pita if i had to list
all packages matched by my current BUILD_PKGS spec (just look at
the examples i've put in my email on that topic to get the idea).
gnome-*/* for package.keywords is already not supported. There is no
difference between what I/pclouds is suggesting for package.env and
package.keywords. What you are really after is for extending the
configuration syntax to support more than just the DEPEND atom. I was
going to reply to that earlier but this patch came up in between me
reading it and, umm, now.
If the configuration syntax is going to be extended, it needs to be
extended across the board. There is already a (closed) bug asking for
regex atom support. This is essentially what you are asking for with the
BUILD_PKGS patch. The difference is that you are completely breaking
away from the mostly standard configuration mechanisms portage currently
supports.
The extension to per-package configuration beyond basic atoms is fine,
but it needs to apply everywhere. If it can remain quick all the better,
but the most important thing is that whatever syntax is used can be used
whereever an atom can be used at the moment.
Since being able to list several env file on a same line doesn't
sounds like a must have feature to me, i would much prefer a
package.env format of that kind:
rule [rule ...]envfile
where rule would be similar to what i've defined for BUILD_PKGS
(with addition of full versioned dep atoms, which is a trivial
change to my code). And if a package happens to match the rules
lists of several lines, then the corresponding env files would all
be sourced, in the order of the said lines. I can try to implement
that if you agree on the idea.
I don't see the difference in the end result. I can only see a difference in
perspective. Perhaps you could enlighten me on this point?
My second concern is about unsupported variables (some of the
FEATURES flags, some of the *DIR locations, etc.): i think they
should be somehow blacklisted, to avoid crazy breakages/bugreports
(btw, a quick look on the variables listed in make.conf.example
made me realize it was not that easy to write an accurate
blacklist, which tends to confirm it's really needed).
Rather than blacklist, I'd think that whitelisting is easier. Anything unknown
to portage (and hence only used on the bash side) will work.
Stuff known to portage that is okay to per-package
--
ACCEPT_KEYWORDS
FEATURES=buildpkg ccache distcc keeptemp keepwork noauto noclean nodoc noinfo
noman nostrip sandbox sfperms suidctl test userpriv usersandbox
USE
Stuff documented but unknown to portage that will work per-package
--
MAKE_OPTS
CFLAGS
CHOST
CTARGET
EBEEP_IGNORE
EPAUSE_IGNORE
NOCOLOR
Stuff known to portage but is portage configuration
---
FEATURES=autoaddcvs cvs digest distlocks fixpackages getbinpkg gpg mirror
notitles severe sign strict
FETCHCOMMAND
GENTOO_MIRRORS
PKGDIR
PORT_LOGDIR
PORTAGE_BINHOST
PORTAGE_NICENESS
PORTAGE_TMPDIR
PORTDIR
PORTDIR_OVERLAY
RESUMECOMMAND
ROOT
RSYNC_EXCLUDEFROM
RSYNC_RETRIES
RSYNC_TIMEOUT
RPMDIR
SYNC
USE_ORDER
* Some of those FEATURES could probably be moved to the supported list
Stuff unknown to portage but is only documented as it affects the default
FETCH_COMMEND
-
http_proxy
ftp_proxy
The question of facing the supported vs unsupported variables is one that we
have been facing for some time. Just looking at the short list of those that
are known to portage and can be supported, it's a hell of a lot of options to
implement as separate configuration files. Thinking of not support per-
package env in some way or another at some point down the track is pure
fantasy.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] emerge -pv and masked dependencies
On Sat, Nov 05, 2005 at 01:55:35AM +0900, Jason Stubbs wrote: On Friday 04 November 2005 22:33, Marius Mauch wrote: Ciaran McCreesh wrote: On Thu, 03 Nov 2005 23:14:20 -0800 Brian [EMAIL PROTECTED] wrote: | emerge -pv package | | would actually continue listing (modified normal)after finding a | dependency is masked rather than stop on, and report only, the first | one. The masked packages would need to be marked as such [hard | masked, keyword masked], possibly shown grouped in blocks [KEYWORD, | HARD MASKED, STABLE]. Problem is, once you hit one bad dependency, you can't carry on and guarantee what the rest of the dep tree is going to be. Example: emerge -pv foo foo DEPENDs upon bar and baz bar DEPENDS upon fnord, and is MASKED baz DEPENDs upon || ( gerbil fnord ) Well, that and other semantic issues (what to do with multiple candidates for example?). Multiple candidates is the most worrying for me as well. a-1.1 is masked and requires =b-1.0. b has 1.0 and 1.1 both of which are masked. b-1.0 requires c-1.0 while b-1.1 requires c-1.1. c-1.1 masked but c-1.0 isn't. Should the above keep going just grab the highest *masked* version at each stage? Either way, while there are bugs such as error messages being truncated, requests such as allow me to break my system easier are truly far from my mind. Of course, supplied patches will always be reviewed. Wait a sec -- emerge -pv means pretend, so it can't break anything. Furthermore, even without the -p, no one is asking it to keep on going, only asking that it show all errors it can find before bailing. Its current behavior is like a compiler that aborts on the first error. I would rather it go on, show me all errors, until it either gets too many, or runs out of them, rather than bailing on the first one. Further, it would be nice if emerge behaved more like make -k, or had an equivalent option. It wouldn't hurt anything if it were to give up on one package and continue to the next if possible. If foo depends on bar, and bar fails, sure bail on foo, but why not continue with the next candidate if it doesn't depend on either? I haven't used python in years, but neither request sounds like that big a deal. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] emerge -pv and masked dependencies
On Fri, 4 Nov 2005 11:19:51 -0800 [EMAIL PROTECTED] wrote: | I swear you have got to be just about the most negative pessimistic | whining poster on this list. Yeah, he's like those silly scientist guys who go around asking pesky questions when someone proposes that an anti-nuclear-missile shield is built. Clearly un-American. Instead, he should jump right in and implement it without bothering to think of the requirements or exactly what the problem to be solved is. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpyXUrSMQVVr.pgp Description: PGP signature
Re: [gentoo-portage-dev] emerge -pv and masked dependencies
On Sat, 2005-05-11 at 01:55 +0900, Jason Stubbs wrote: On Friday 04 November 2005 22:33, Marius Mauch wrote: Ciaran McCreesh wrote: On Thu, 03 Nov 2005 23:14:20 -0800 Brian [EMAIL PROTECTED] wrote: | emerge -pv package | | would actually continue listing (modified normal)after finding a | dependency is masked rather than stop on, and report only, the first | one. The masked packages would need to be marked as such [hard | masked, keyword masked], possibly shown grouped in blocks [KEYWORD, | HARD MASKED, STABLE]. Problem is, once you hit one bad dependency, you can't carry on and guarantee what the rest of the dep tree is going to be. Example: emerge -pv foo foo DEPENDs upon bar and baz bar DEPENDS upon fnord, and is MASKED baz DEPENDs upon || ( gerbil fnord ) Well, that and other semantic issues (what to do with multiple candidates for example?). Multiple candidates is the most worrying for me as well. a-1.1 is masked and requires =b-1.0. b has 1.0 and 1.1 both of which are masked. b-1.0 requires c-1.0 while b-1.1 requires c-1.1. c-1.1 masked but c-1.0 isn't. Should the above keep going just grab the highest *masked* version at each stage? Isn't that what users end up with after adding each package to package.keywords then emerge-pv package again, and again... unless they do detailed research for each failed dep. I know I never looked that close at the packages each time it happened as long as it wasn't hard masked. Either way, while there are bugs such as error messages being truncated, requests such as allow me to break my system easier are truly far from my mind. Of course, supplied patches will always be reviewed. -- Jason Stubbs Well, I don't know that I could supply patches to portage. I have enough to keep track of in porthole let alone learn the intricacies of package management. It sounds like this is something easier done in porthole where we can display all relevant packages in a dialog with checkboxes for package selection and possibly an adjustable search depth. That way package research could be done in porthole's main window to help decide whether they wish to proceed and or which version to select. A real world example is gnome-base/gnome. The last couple updates have resulted in numerous masked packages needed to be added to package.keywords. Thanks for your time and input everyone. -- Brian [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] emerge -pv and masked dependencies
On Saturday 05 November 2005 04:19, [EMAIL PROTECTED] wrote: On Sat, Nov 05, 2005 at 03:44:30AM +0900, Jason Stubbs wrote: Nobody else has shown a real example, why should I? ... I am focusing on what it could do. I stated all the options in my previous email. ... To restate: How often is it there is exactly one masked version available? What to do when there are two? How old are you? You sound like some crotchety old fart on a rocking chair on his porch. 26; almost 27. Good god. Probably once or twice a month I read about some program that sounds interesting, run emerge -p on my amd64, it complains that some dependency is masked, I edit /etc/portage/packages.keywords, emerge -p again, get another complaint about some other top level dependency, rinse, lather, repeat, until I have a half dozen additions or give up in disgust. If you have never had this happen, then I feel sorry for you for being so unadventurous. I run ~amd64 but always run whatever the latest packaged KDE is available. Unmasking all of KDE would fit in your category I guess, but I think the discussion with TGL tied with package.unmask would solve that. The only other times I run into masked packages are those that are missing an amd64 keyword. And the only way I can provide a real world example is wait til it comes around again on the gitar, to quote Arlo, and I am not going to waste my time trying to remember to come back to this dicsussion then, it will be quite cold in its grave, obviously where you want it to go. I don't really want a real world example. You seemed to want one. I swear you have got to be just about the most negative pessimistic whining poster on this list. Heh. This made me laugh. If negative means that I try to be pro-active by searching for problems, pessimistic means that I do find a lot of problems, and whining means that I keep going back to points that haven't been addressed, then why sure I am! ;) -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] cache subsystem replacement
So... the cache rewrite is in svn now. Will nuke UNUSED_* next day or so, wanted to get the subsystem in before tweaking it further. ~harring pgp2SiFvy5R9Z.pgp Description: PGP signature
