betelgeuse@pena /usr/portage/profiles $ find -name "*bashrc*" ./base/profile.bashrc ./default-bsd/fbsd/6.2/profile.bashrc ./default-bsd/profile.bashrc ./selinux/amd64/profile.bashrc ./selinux/profile.bashrc ./selinux/2005.1/amd64/profile.bashrc ./default-linux/ppc/dev/ppc64/2007.0/multilib/profile.bashrc ./default-linux/ppc/dev/ppc64/2007.0/32bit-userland/profile.bashrc ./default-linux/ppc/dev/ppc64/2007.1/64bit-userland/profile.bashrc ./default-linux/ppc/dev/ppc64/2007.1/32bit-userland/profile.bashrc ./default-linux/ppc/ppc64/2006.0/multilib/profile.bashrc ./default-linux/ppc/ppc64/2006.0/64bit-userland/profile.bashrc ./default-linux/ppc/ppc64/2006.1/multilib/profile.bashrc ./default-linux/ppc/ppc64/2006.1/64bit-userland/profile.bashrc ./default-linux/ppc/ppc64/2006.1/64bit-userland-gcc4/profile.bashrc ./default-linux/ppc/ppc64/2006.1/32bit-userland/profile.bashrc ./default-linux/ppc/ppc64/2007.0/64bit-userland/profile.bashrc ./default-linux/ppc/ppc64/2007.0/32bit-userland/profile.bashrc ./default-linux/ppc/2005.1/ppc64/multilib/profile.bashrc ./default-linux/ppc/2005.1/ppc64/64bit-userland/profile.bashrc ./default-linux/x86/dev/2007.1/server/profile.bashrc ./default-linux/x86/2006.1/server/profile.bashrc ./default-linux/x86/2007.0/server/profile.bashrc ./default-linux/mips/mips64/multilib/profile.bashrc ./default-linux/amd64/profile.bashrc ./default-linux/amd64/2006.0/no-symlinks/profile.bashrc ./default-linux/amd64/2006.1/server/profile.bashrc ./default-linux/amd64/2007.0/server/profile.bashrc ./default-linux/ppc64/dev/multilib/profile.bashrc ./default-linux/ppc64/dev/2005.1/no-multilib/profile.bashrc ./hardened/amd64/profile.bashrc ./uclibc/profile.bashrc ./default-darwin/macos/10.4/profile.bashrc
The problem with profile.bashrc is that it's being used for some Portage-specific things... So either profile.bashrc has to become a lot more restricted in what it's allowed to do or it remains a Portageism upon which ebuilds cannot rely.
(In reply to comment #1) > The problem with profile.bashrc is that it's being used for some > Portage-specific things... So either profile.bashrc has to become a lot more > restricted in what it's allowed to do or it remains a Portageism upon which > ebuilds cannot rely. > Well you should be needing this for the BSD profiles to work: betelgeuse@pena /usr/portage/profiles $ cat ./default-bsd/fbsd/6.2/profile.bashrc alias make=gmake alias patch=gpatch alias sed=gsed alias awk=gawk
Paludis at least does its own handling for sed etc using PATH. There're various gotchas with aliases...
(In reply to comment #1) > The problem with profile.bashrc is that it's being used for some > Portage-specific things... So either profile.bashrc has to become a lot more > restricted in what it's allowed to do or it remains a Portageism upon which > ebuilds cannot rely. > This is a non-sequitur. What we choose to run on our machine, or in the profiles we customise is our business, not that of any package manager. As such, it does not follow that one must require any sort of restriction before an rc-file can be specified in the context of an OS distribution, and certainly not a meta-distribution. How profile.bashrc is used is not the concern of an independent specification purported to enable interoperability. It is a fact of life that admins, as well as distributions, need to customise their systems via script. Since ebuilds/ebuild.sh are implemented in BASH, profile.bashrc is the logical name (for the distribution-builder at least). If they were not, perhaps something like .pyrc or .javarc could be used instead. In any event, the bashrc is not used for ebuilds to rely on. It is used by us to make sure everything we need to happen, will happen. If that is out of scope for your current work, perhaps you could add a new chapter detailing what configuration hooks a package manager must execute/which folders it must look in (relative to a repository root), in order to comply with the Gentoo PMS, for BASH .ebuild repositories at least. This would enable interoperability at the admin-level, which I believe to be the whole point of allowing various projects to compete for Gentoo (and downstream projects') users, and the reason Gentoo developers endeavour to ensure ebuilds comply to the specification.
(In reply to comment #4) > This is a non-sequitur. What we choose to run on our machine, or in the > profiles we customise is our business, not that of any package manager. As > such, it does not follow that one must require any sort of restriction before > an rc-file can be specified in the context of an OS distribution, and certainly > not a meta-distribution. Erm. It's not what you choose to run. It's what you choose to run as part of a package manager internal process that interacts intimately with the package manager's innards. > How profile.bashrc is used is not the concern of an independent specification > purported to enable interoperability. Of course it is. To enable interoperability, the specification would have to ensure that profile.bashrc contained only interoperable code. > It is a fact of life that admins, as well as distributions, need to customise > their systems via script. And what does this have to do with profile.bashrc? > In any event, the bashrc is not used for ebuilds to rely on. It is used by us > to make sure everything we need to happen, will happen. Er, no. profile.bashrc is used to tinker with Portage's behaviour. As such, we either leave it as a Portage-specific thing, or impose a huge number of restrictions on it so that it isn't Portage-specific. > If that is out of scope for your current work, perhaps you could add a new > chapter detailing what configuration hooks a package manager must execute/which > folders it must look in (relative to a repository root), in order to comply > with the Gentoo PMS, for BASH .ebuild repositories at least. Configuration's deliberately left to the package manager to decide upon. > This would enable interoperability at the admin-level, which I believe to be > the whole point of allowing various projects to compete for Gentoo (and > downstream projects') users, and the reason Gentoo developers endeavour to > ensure ebuilds comply to the specification. If you'd like a specification for Portage's configuration files, feel free to create one, but I doubt anyone (including the Portage people, who like the freedom to add new configuration things whenever they want) would be interested in sticking to it.
(In reply to comment #5) > Erm. It's not what you choose to run. It's what you choose to run as part of a > package manager internal process that interacts intimately with the package > manager's innards. > That sounds very impressive; however it is what I and many other Gentoo users have been doing for quite a while. And it is incorrect: this is much more to do with interacting with the ebuild, or setting up system-specific things which Gentoo cannot, and would not want to, be concerned about. Or are you saying all bashrc's should be disallowed by PMS? > > How profile.bashrc is used is not the concern of an independent specification > > purported to enable interoperability. > > Of course it is. To enable interoperability, the specification would have to > ensure that profile.bashrc contained only interoperable code. > Another non-sequitur: I suggest you consider the POSIX specification, as a counter-example. (I'm assuming you've read at least parts of it. If not, please do so, and you will see what I mean.) > > It is a fact of life that admins, as well as distributions, need to customise > > their systems via script. > > And what does this have to do with profile.bashrc? > I'm amazed you should need to ask. However let me be explicit: as an admin I may wish to customise what happens. How and why is outside the scope of the spec. That it is allowed, is in-scope. > > In any event, the bashrc is not used for ebuilds to rely on. It is used by us > > to make sure everything we need to happen, will happen. > > Er, no. profile.bashrc is used to tinker with Portage's behaviour. As stated, it is about interaction with the ebuild. Should the downstream distribution only support a particular package manager, they would of course be able to use whichever implementation-specific configuration they like. > As such, we > either leave it as a Portage-specific thing, or impose a huge number of > restrictions on it so that it isn't Portage-specific. > Since your premise is false so is your conclusion. You also appear to be unaware that pkgcore supports bashrc, so this is not portage-specific at all. Further, you again appear to misunderstand the specification process: for system or implementation-specific things, most specifications allow undefined, or implementation-specific, behaviour within a defined scope. The bashrc is such, for BASH ebuilds. Additionally, most specifications allow extensions via MAY. I fail to see the utility in not providing this, but I would be willing to accept this as an extension, if you feel unable or unwilling to implement it in Paludis. I am unaware of how Gentoo developers collectively feel, of course. It is not the specification's place to limit what the users can do: only to make sure that they know what they can expect, and are aware when they step outside of specified behaviour. > Configuration's deliberately left to the package manager to decide upon. > Indeed; there is a case however for a Gentoo arch, or a downstream distribution, or an overlay provider, to customise what happens during the ebuild process. Specifying a minimal configuration hook in the form of bashrc has utility, or it would never have been implemented, nor would a Gentoo developer have filed this bug. I note in passing that the utility is undefined and potentially unbounded, so focussing solely on the one configuration item so far raised, will not suffice to answer the wider point. (I assume you now understand what that is, as I have explained it twice. Should you not understand, please tell me, along with which parts cause confusion, and how, and I shall clarify further.) > > This would enable interoperability at the admin-level > If you'd like a specification for Portage's configuration files, feel free to > create one, but I doubt anyone (including the Portage people, who like the > freedom to add new configuration things whenever they want) would be interested > in sticking to it. > An interesting opinion; it adds nothing useful however, so I'll leave it there. This is about PMS, so that downstream can have the flexibility they require in portage and pkgcore, as well as paludis should it choose to implement the extension (if the consensus is that this should be an extension and not simply part of the base spec.)
(In reply to comment #6) > [...] The point here is that if profile.bashrc is specified in PMS, then all package managers will be expected to run it. (I suppose it could say that it's optional, but it seems fairly pointless to mention it at all if it doesn't make any requirement.) If all package managers are expected to run it, then it must only contain code that will work in all package managers (at least in main-tree profiles - no-one cares if you violate the spec in your own private profile). The question in this bug is: should we require all package managers to run profile.bashrc, and limit its contents accordingly? Or should we make it Portage-only (apparently the pkgcore developers either don't expect people to add Portage-specific things or don't care) and allow people to add code that only works in Portage?
The question is more why Ranjit thinks that using the tree's profile.bashrc is the best way for administrators to execute code on user systems, especially since your package manager of choice already provides a separate global bashrc in the same place as all the other global administrator-supplied configuration for doing just what he describes.
