Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Ok, no separate glep for home installation:
So i need some clues how to install plugins into home - attached is some
ebuild patch sample (actually not a diff output) how i would try to start
with vim-plugins.eclass, as a discussion base.
Variables to be set by portage:
PREFIX=/home/haubi
AFFIX=home/haubi/ (not used here)
INSTALL_TARGET_TYPE=home (value is found in the SUPPORTS
metadata-variable)
This is a new variable which needs a better name, or even a portage-function
for querying the install target type, which comes from the
'emerge --target home' bit by Brian Harring.
Is it confusing when PREFIX contains home-dirs - should another variable
name be used for home-dir, or should PREFIX/AFFIX be renamed - suggestions ?
Where should additional documents (seen in current vim-plugin_src_install)
go to ?
Can `id -un`:`id -gn` (maybe wrapped by some portage function, using glep 27
for non-home-target) be used to set the owner of the files ?
~haubi
begin 666 vim-plugins-home.patch
M(!V:6TMQU9VEN7W-R8U]I;G-T86QL*D@PHM( @(!L;V-A;!FBL@
M( @(QO8V%L([EMAIL PROTECTED]B!GF]U!D97-T8F%S92!D97-T9ERBL@BL@
M( @(EF(%L@(B1[24Y35$%,3%]405)'151?5%E017TB(#T@(FAO;64B(%T*
M*R @( @=AE;@HK( @( @( @(R!T:ES(ES(YO=!G;5P(#(WBL@
M( @( @(!UV5R/6!I9 M=6Y@BL@( @( @(!GF]U#U@:[EMAIL PROTECTED]
M8 HK( @( @( @95S=)AV4](B1[4%)%1DE8?2(@( C(%!2149)6#TO
M:]M92\\=7-ECX**R @( @( @(1EW1D:7(](BYV:6TBBL@( @(5L
MV4**R @( @( @(,@9VQE R-R!A'!L:65S(AEF4@/PHK( @( @
M( @=7-ECUR;V]TBL@( @( @(!GF]U#UR;V]TBL@( @( @(!D
M97-T8F%S93TB)'M04D525A]+W-H87)E+W9I;2(**R @( @( @(1EW1D
M:7(](G9I;69I;5S(@HK( @(!F:0H*( @( @96)E9VEN():7AI;F@
M9FEL92!P97)M:7-S:6]NR(*( @( @(R!-86ME('-UF4@5R;7,@87)E
M(=O;V0*( @( @8VAM;[EMAIL PROTECTED](@82MR6 DU-]('Q\(1I92 B8VAM;V0@
M9F%I;5D(@HM( @(!F:6YD([EMAIL PROTECTED](@(=P;W)T86=E)R M97AE
M8R!C:]W;B!R;V]T(=[?2@[EMAIL PROTECTED]'[EMAIL
PROTECTED]EE()C:]W;B!F86EL960BBT@
M( @(9I;F0@)'M3?2 M9W)O=7 @)W!OG1A9V4G(UE5C(-H9W)P(')O
M;W0@)WM])R!.R!\?!D:64@(F-H9W)P(9A:6QE9(**R @( @9FEN9 D
MU-](UUV5R( G]R=%G92@+65X96,@8VAO=VX@(B1[=7-EGTB(=[
M?2@[EMAIL PROTECTED]'[EMAIL PROTECTED]EE()C:]W;B!F86EL960BBL@(
@(9I;F0@)'M3?2 M
M9W)O=7 @)W!OG1A9V4G(UE5C(-H9W)P((DV=R;W5P?2(@)WM])R!
M.R!\?!D:64@(F-H9W)P(9A:6QE9(*( @( @965N9 D/PH**'-N:7!P
[EMAIL PROTECTED]AE(1O8W5M96YT871I;VXI@HM( @(!D;V1IB O=7-R+W-H87)E
M+W9I;0HM( @(!M=B DU-](1[1'TO=7-R+W-H87)E+W9I;2]V:6UF:6QE
MPHK( @(!D;V1IB B)'MD97-T8F%S97TBBL@( @(UV(1[4WT@(B1[
?1'TDV1EW1B87-E?2\DV1EW1D:7)](@H@('T*@``
`
end
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Tue, 24 May 2005 11:53:30 +0200 Michael Haubenwallner [EMAIL PROTECTED] wrote: | Variables to be set by portage: | PREFIX=/home/haubi | AFFIX=home/haubi/ (not used here) Hrm. So what do we use for finding out where our non-home deps are installed then? | Where should additional documents (seen in current | vim-plugin_src_install) go to ? I'd suggest that you try something like gkrellm plugins -- there're some nice subtleties with vim plugins to do with docs tag generation that will require patching vim itself for things to work properly. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp97sHPV1oVS.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Tue, May 24, 2005 at 11:07:54AM +0100, Ciaran McCreesh wrote:
On Tue, 24 May 2005 11:53:30 +0200 Michael Haubenwallner
[EMAIL PROTECTED] wrote:
| Variables to be set by portage:
| PREFIX=/home/haubi
| AFFIX=home/haubi/ (not used here)
Hrm. So what do we use for finding out where our non-home deps are
installed then?
add a bash func that abuses the ebd pipes to query
portage directly.
get_installed_prefix ${atom} might fly, although naming/ironing out
semantics is required.
~brian
pgp3BQNKv9m2m.pgp
Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Jason Stubbs wrote: On Friday 20 May 2005 21:30, Michael Haubenwallner wrote: snip 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. Hmm - are there ideas/plans already around how that will change - did i miss something ? ~haubi -- Michael HaubenwallnerSALOMON Automation GmbH Forschung Entwicklung A-8114 Friesach bei Graz mailto:[EMAIL PROTECTED] http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html -- gentoo-dev@gentoo.org mailing list
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] 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] new glep draft: Portage as a secondary package manager
On Thu, 19 May 2005 10:18:03 +0200 Michael Haubenwallner [EMAIL PROTECTED] wrote: | So unless it is shown otherwise, home install support requires: | | But imo the home-support _really_ requires another glep, as there | are lots of more issuses than for the prefix-support. Naah. Not really. The hard part is figuring out how to correctly change all shell scripts that start with #!/bin/sh to use the portage-provided sh instead, all perl scripts that start with #!/usr/bin/perl or #!/usr/bin/env perl to use the portage-provided perl instead, how to fix all autotools checks which look in /usr/lib first and so on. From an ebuild perspective, which is where most of the work will be, asking portage just where it *should* look is really just a sidenote that needs to be documented somewhere. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpPRjnQJOTKt.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Ciaran McCreesh wrote:
On Thu, 19 May 2005 10:18:03 +0200 Michael Haubenwallner
| But imo the home-support _really_ requires another glep, as there
| are lots of more issuses than for the prefix-support.
Naah. Not really. The hard part is figuring out how to correctly change
all shell scripts that start with #!/bin/sh to use the portage-provided
sh instead, all perl scripts that start with #!/usr/bin/perl or
#!/usr/bin/env perl to use the portage-provided perl instead, how to fix
all autotools checks which look in /usr/lib first and so on. From an
ebuild perspective, which is where most of the work will be, asking
portage just where it *should* look is really just a sidenote that needs
to be documented somewhere.
Here some things imo not needed to mention in the glep:
Most of the packages (not ebuilds) wont work on systems without
/bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need to
have a Bourne-Shell installed in /my/prefix/bin/sh instead of /bin/sh.
When a user wants to use things (including portage) from /my/prefix,
he/she has to source /my/prefix/etc/profile (this could be in the glep).
Once this is done, this line will find the portage-installed
interpreters:
#! /usr/bin/env {bash,perl,python,whatever}
When portage starts the ebuild-daemon, i've seen that portage removes
PATH from environment and lets bash use its default-PATH.
So i've added one more patch to bash.ebuild to change the default-PATH
to /my/prefix/bin:/usr/bin:/bin if prefix!=/usr instead of
/usr/local/bin:/usr/bin:/bin, which is done in bash.ebuild right now.
autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in
case of prefix!=/usr, so gcc searches in /my/prefix/lib:/usr/lib:/lib
for libraries by default, and the checks should rely on the compiler to
find the right libraries when configuring.
Another one is ld.so.conf:
All of the shlib-loaders know some kind of LD_LIBRARY_PATH in environ,
and instead of writing /my/prefix/etc/ld.so.conf, portage puts the
LDPATH-bits from env.d/ into this variable, so finding the right
shared-libs does work.
So at least bash is required to be installed into same prefix as
portage, and its easier to have gcc here too instead of setting
CPATH and LIBRARY_PATH to /my/prefix/{include,lib} and providing gcc.
And it is necessary to have different baselayouts and profiles necessary
for different systems (solaris,aix,hpux,...) to keep the differences
outside of portage.
And for a package (not the ebuild) which cannot install to prefix, it is
unlikely that it makes sense to install it besides the primary prefix.
~haubi
--
Michael HaubenwallnerSALOMON Automation GmbH
Forschung Entwicklung A-8114 Friesach bei Graz
mailto:[EMAIL PROTECTED] http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Thu, 19 May 2005 13:05:20 +0200 Michael Haubenwallner
[EMAIL PROTECTED] wrote:
| Most of the packages (not ebuilds) wont work on systems without
| /bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need
| to have a Bourne-Shell installed in /my/prefix/bin/sh instead of
| /bin/sh.
So what if /bin/sh is a nastily h0rked non-POSIX implementation? Or what
if we have packages with a dep upon a specific sh version? The portage
provided version must be used in all cases.
| Once this is done, this line will find the portage-installed
| interpreters:
| #! /usr/bin/env {bash,perl,python,whatever}
No good, because we won't be using the portage-provided env binary. And
that only works for things that actually use env (which is considered
discouraged).
| autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in
| case of prefix!=/usr, so gcc searches in
| /my/prefix/lib:/usr/lib:/lib for libraries by default, and the
| checks should rely on the compiler to find the right libraries when
| configuring.
I could dig out a rather large list of annoying counterexamples, all of
which would need manual fixing...
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
pgpMnzJOB3wRE.pgp
Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
One general Question:
How can open source packages work on Unices which are non-Gentoo-Linux
if there are that many unresolved issues you try to point out ?
This is what autoconf and libtool are for, and if a package lacks using
them, autoconf/libtool-like trickery has to be done in ebuilds.
There are always 'what if' situations, where the secondary package
manager cannot be responsible for. Portage and ebuilds have to avoid
_all_ those situations _only_ if portage is the _primary_ pkg mgr.
As secondary pkg mgr, _some_ basic working things must be presumeable.
Ciaran McCreesh wrote:
On Thu, 19 May 2005 13:05:20 +0200 Michael Haubenwallner
[EMAIL PROTECTED] wrote:
| Most of the packages (not ebuilds) wont work on systems without
| /bin/sh (Bourne-Shell, not bash) and /usr/bin/env, so there's no need
| to have a Bourne-Shell installed in /my/prefix/bin/sh instead of
| /bin/sh.
So what if /bin/sh is a nastily h0rked non-POSIX implementation? Or what
if we have packages with a dep upon a specific sh version? The portage
provided version must be used in all cases.
If /bin/sh is a bad shell, many packages wouldn't work,
independend if installed by hand or by portage/ebuilds.
And if a package depends on specific version, it is able to find such a
version itself or at least to specify the location of the right version.
| Once this is done, this line will find the portage-installed
| interpreters:
| #! /usr/bin/env {bash,perl,python,whatever}
No good, because we won't be using the portage-provided env binary. And
that only works for things that actually use env (which is considered
discouraged).
Same here, if a package cannot operate with /usr/bin/env on
non-Gentoo-Linuxes, and is dedicated to run on such Unices,
it should be able to find the right one or get it specified.
No somewhat correct package, which says to run on Unix, should have
hardcoded '#! /usr/bin/perl' but find it in PATH.
| autoconf-checks: i configure gcc '--with-local-prefix=/my/prefix' in
| case of prefix!=/usr, so gcc searches in
| /my/prefix/lib:/usr/lib:/lib for libraries by default, and the
| checks should rely on the compiler to find the right libraries when
| configuring.
I could dig out a rather large list of annoying counterexamples, all of
which would need manual fixing...
Sure, but what's the problem with manual fixing ?
The one who needs it will look for how to fix it.
And why not let portage support features not required for Gentoo-Linux ?
Portage is just another open source package, which is able to be ported
to other Unices, with the power to become _the_ secondary pkg mgr.
~haubi
--
Michael HaubenwallnerSALOMON Automation GmbH
Forschung Entwicklung A-8114 Friesach bei Graz
mailto:[EMAIL PROTECTED] http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Thu, 19 May 2005 14:46:34 +0200 Michael Haubenwallner [EMAIL PROTECTED] wrote: | How can open source packages work on Unices which are non-Gentoo-Linux | if there are that many unresolved issues you try to point out ? The issues I'm pointing out are things which are issues with the way ebuilds are set up and the way builds are done in general. They're some of the same issues that you'll encounter when doing ports to nasty unix clones. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpjxNeUbEi4q.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
- Original Message - From: Marius Mauch [EMAIL PROTECTED] Ciaran McCreesh wrote: snip As for the new metadata variable, I think it should be a complement to RESTRICT (not limited to prefix). As the name for this var I suggest SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME it would look like: SUPPORTS=prefix prefix-home (as /usr is implicit) For the values of the SUPPORTS-Variable (i like the name) i'd prefer some words pointing to the package-manager used (primary/secondary/home), fex secondarypm homepm or 2ndpm homepm or the like (more ideas welcome), because /usr is a 'prefix' too. But here's just one point to think of how to avoid redundant information in ebuilds: The SUPPORTS-Variable _will_ be necessary for home-installation, sure. But when an ebuild has KEYWORDS='sparc' and SUPPORTS='2ndpm', this does not automatically imply that it compiles on a 'sparc-solaris' - this keyword has to be added explicitly. But how likely is it that on 'sparc-solaris' portage would be the primary pkg mgr installing into /usr ? So when an ebuild has 'sparc-solaris' in keywords, imo one can assume that it _does_ support secondarypm (also look at http://www.gentoo.org/proj/en/glep/glep-0022.html#reasonable-defaults). Or is this assumption too much implicit ? Well, right, this will break the bsd keyworded ebuilds when used with a secondary pm unless they support it, so this would not be a reasonable way to go, just a point to think of (imo installing into primary prefix with a secondary pkg mgr is sth. weird...) ~haubi PS: sorry for beeing offline most of the time, i'm on holiday until May 17, just sporadically reading mail, and completely offline from May 13 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Michael Haubenwallner wrote: - Original Message - From: Marius Mauch [EMAIL PROTECTED] Ciaran McCreesh wrote: snip As for the new metadata variable, I think it should be a complement to RESTRICT (not limited to prefix). As the name for this var I suggest SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME it would look like: SUPPORTS=prefix prefix-home (as /usr is implicit) For the values of the SUPPORTS-Variable (i like the name) i'd prefer some words pointing to the package-manager used (primary/secondary/home), fex secondarypm homepm or 2ndpm homepm or the like (more ideas welcome), because /usr is a 'prefix' too. That looks horribly confusing. Doesn't really matter if /usr is a prefix or not. But here's just one point to think of how to avoid redundant information in ebuilds: The SUPPORTS-Variable _will_ be necessary for home-installation, sure. But when an ebuild has KEYWORDS='sparc' and SUPPORTS='2ndpm', this does not automatically imply that it compiles on a 'sparc-solaris' - this keyword has to be added explicitly. But how likely is it that on 'sparc-solaris' portage would be the primary pkg mgr installing into /usr ? Depends if there will be a Gentoo/OpenSolaris ... So when an ebuild has 'sparc-solaris' in keywords, imo one can assume that it _does_ support secondarypm (also look at http://www.gentoo.org/proj/en/glep/glep-0022.html#reasonable-defaults). Or is this assumption too much implicit ? It would be confusing IMO. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, May 09, 2005 at 03:46:57AM +0300, Marius Mauch wrote: Brian Harring wrote: Clarify please :) Offhand, I don't see why a bin repo for a home target isn't viable, along with a vdb repo in the same location. It's a bit trickier, but I suspect it might be a bit more flexible in the long run. I don't think that's possible without a lot of hacking for many packages as $HOME will be expanded at build time and might be included in the resulting binaries. Or in other words: If it works, we don't need $PREFIX support at all as packages could be relocated at merge time. Was referencing per home binrepo's; basically (if desired by the admin/user), binpkg backups of per user home targets. End result is per user FEATURES=buildpkg support, with the binpkgs safely tucked away within $HOME of the user. If we're already doing the dep calculation of what nodes are needed, and where (home prefix, or global, etc), don't see why that info can't be tucked away and used as a restriction for the binpkg generated for that particular user... ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager OT
On Sat, May 07, 2005 at 04:51:36PM +0100, Ciaran McCreesh wrote: | 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. You and I know that. Brian seems to be assuming that the people that do the work will know how to handle every single package in the tree. You're agreeing to the point kito made (my point spelled out for you) and you take a parting shot at me? Was that really needed? Eh? No. It's about getting a major change done cleanly and without causing another disaster of OSX-sized proportions. Fud. OSX was a disaster _because_ it was implemented and dumped on everyone else, without involving anyone else. This discussion/glep is to hash out the idea and issues, _rather_ then making it official and dumping the issues on others to address. | 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? I've done that already several times in this thread. You've suggested ICANINSTALLTO, which has become SUPPORTS. Beyond that you've either insulted those involved (the initial IRC discussion), or resorted to heckling the proposal via the same angle repeatedly. Funny part is above you agree on the response I've stated to you repeatedly, only after it's written by someone else. Intermixing another lovely bit of your slander/attacks. 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. I suggested haubi write it up as a glep, and bring it to this ml for the purpose of discussion of it, issues and all. The funny thing is, if we just slipped the changes into portage and released it, we would be sidestepping the issues. It would be the OSX disaster. Write the sucker up as a glep, issues and all for discussion, and you attack those involved as trying to bypass the discussion. So pretty much it's screwed if you do, screwed if you don't. That's definitely one way to block progress on it; even bringing up the idea equals you flaming/attacking those involved with it. The entertaining aspect of this whole exchange is that you agree to jason's rephrasing of it (plus binpkg issues), which is the same damn thing you've been arguing against. Basically, you've been an ass for the sake of being an ass thus far for anyone involved in the proposal. It's not needed, and just wasted a chunk of my time, and yours for no valid reason. ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Sun, May 08, 2005 at 12:47:05AM +0900, Jason Stubbs wrote: 6 Portage must disallow the creation of binary packages where all dependencies are not in the same PREFIX. First level, second level... ? I'd rather see the deps/prefix data slapped into the binpkg, and tracked alongside, and verified prior to installation. Reason being- say a package links against libssl, and is built to be installed into a user's directory (irssi for example). A restriction of the sort you're specifying would block irssi from ever being binpkg'd for home installation. I was planning to summarize home install support here, Clarify please :) Offhand, I don't see why a bin repo for a home target isn't viable, along with a vdb repo in the same location. It's a bit trickier, but I suspect it might be a bit more flexible in the long run. ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager OT
On Sun, 8 May 2005 02:58:32 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Write the sucker up as a glep, issues and all for discussion, and you | attack those involved as trying to bypass the discussion. Bah. It should have been written up as a GLEP with the initial feedback already incorporated. | The entertaining aspect of this whole exchange is that you agree to | jason's rephrasing of it (plus binpkg issues), which is the same damn | thing you've been arguing against. I'm not arguing against the general concept. I'm arguing against some of the implementation issues which you and Michael are trying to gloss over. You know this, stop trying to spin it any other way. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpZqwrz5UchI.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Brian Harring wrote: Clarify please :) Offhand, I don't see why a bin repo for a home target isn't viable, along with a vdb repo in the same location. It's a bit trickier, but I suspect it might be a bit more flexible in the long run. I don't think that's possible without a lot of hacking for many packages as $HOME will be expanded at build time and might be included in the resulting binaries. Or in other words: If it works, we don't need $PREFIX support at all as packages could be relocated at merge time. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Sat, May 07, 2005 at 02:39:20AM +0100, Ciaran McCreesh wrote:
'tweak' is too mild a term... As far as I can tell I'm the only person
who's bothered to actually even try to look at this from an ebuild
perspective
Surprisingly, not quite true (was fun stating it I'm sure though).
-- not pretty... For every package in the tree that has a
sed -e 's,/usr/local,/usr,g' there's another that would need a sed
turning /usr into whatever prefix ends up as
Dodging the valid sed criticism, no, a secondary sed would be
something of a hack. Substitue the prefix var instead.
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.
The change in conventions for writing ebuilds _is_ falling on
ebuild dev's heads.
Remember that in the grand scheme of things, the required changes to how
ebuilds are written is a helluva lot more important then basically
retrofitting existing ebuilds.
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_.
Basically, if the only thing you can point out as a con against this
glep is changes -the interested parties would have to make to the
existing tree-, please summarize rather then dragging this out over a
week. If you're after arguing that the potential complexity involved
in mapping an ebuild into a nonstandard prefix is too large, summarize
and state that, etc.
Getting a bit tired of repeatedly stating (whether irc or ml) yes,
the existing tree would require modification, and yes, you don't have
to do the heavy lifting, those interested do.
If this portion of the discussion is to continue, please split
it off into a seperate thread, thus far it's hijacked the discussion
and is more centered on crappy ebuilds/packages, rather then potential
changes. Not saying it's not a valid point, just saying yeah, you
got your point across, now can we move on to the other portions that
need discussion?. 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.
| Meanwhile, iirc from the last irc conversation on this, either you or
| dsd brought up the point of needing to be able to query if (using vim
| as an example) vim-core was $home, rather then usr|$PREFIX. Care to
| elaborate a bit? Mainly wondering if to encompass your requests, it
| might require extra metadata from the depend standpoint.
Ok, say we use ICANINSTALLTO (name!). Then if we have prefix as the
destination, there's no problem, because we know that all our deps are
installed in ${PREFIX} as well. However, if we're installing to home,
we need to know where our deps are -- for home installs I'm presuming
we don't force a full dep tree in home (unlike for prefix). This
*could* still be done with ${PREFIX} I guess? Or to avoid confusing
things, ${DEPS_PREFIX}? Not really sure...
Could you break it down to if I'm going into home, I need xyz at the
home level rather then global/usr ?
as in something along the lines of
if dep_installation_target some-vim-dep home; then
# do the home equiv
else
# do the global equiv
fi;
?
~brian
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Ciaran McCreesh wrote:
Ok, say we use ICANINSTALLTO (name!). Then if we have prefix as the
destination, there's no problem, because we know that all our deps are
installed in ${PREFIX} as well. However, if we're installing to home,
we need to know where our deps are -- for home installs I'm presuming
we don't force a full dep tree in home (unlike for prefix). This
*could* still be done with ${PREFIX} I guess? Or to avoid confusing
things, ${DEPS_PREFIX}? Not really sure...
As for the new metadata variable, I think it should be a complement to
RESTRICT (not limited to prefix). As the name for this var I suggest
SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME
it would look like:
SUPPORTS=prefix prefix-home (as /usr is implicit)
Marius
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
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. | 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. | 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. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpu1p1IofnsX.pgp Description: PGP signature
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] new glep draft: Portage as a secondary package manager
On Saturday 07 May 2005 23:49, Ciaran McCreesh wrote: 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. The being able to say is the harder part. ;) Having a package find out where it's dependencies are is quite simple. Enhancing portageq to support it will be one of the smaller tasks in all of this. Wrapping that with a dev-friendly bash function will be even easier. So to summarise prefixed install support thus far: 1 Portage needs to be enhanced with a new SUPPORTS so that packages can specify that they can install into a non-standard location. 2 Portage needs to be enhanced with new ebuild support functions for detecting the location of a dependency. 3 Portage needs to supply PREFIX and AFFIX variables to those ebuilds that support non-standard location installs, which specify executable and configuration/data locations respectively. 4 Portage needs a base PREFIX and AFFIX to install to by default. 5 Packages need to be updated for support of these feature. - Packages that have a standard location of / rather than /usr install into AFFIX rather than PREFIX. And to add my own little pieces of wisdom: 6 Portage must disallow the creation of binary packages where all dependencies are not in the same PREFIX. 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. I was planning to summarize home install support here, but your statement above has confused me a little. Is there any case where a package *must* have a dependency installed globally? If so, I can't see it. So unless it is shown otherwise, home install support requires: 8 SUPPORTS needs to be enhanced with another indicator for packages to specify that they can do home installs. 9 Emerge needs to be enhanced to allow the user to specify if they want a home install or a prefixed install of a package. 10 Portage needs to tell the ebuild whether it should perform a home install or a prefixed install. Does that about cover it? Regards, Jason Stubbs pgpuFHrpmsrf0.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Sat, 7 May 2005 10:31:49 -0500 Kito [EMAIL PROTECTED] wrote: | 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. You and I know that. Brian seems to be assuming that the people that do the work will know how to handle every single package in the tree. | 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. Eh? No. It's about getting a major change done cleanly and without causing another disaster of OSX-sized proportions. | 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? I've done that already several times in this thread. | 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. Needs to be easily accessible from the ebuild. Parsing things in bash is a nuisance. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp0FgWH7iSIZ.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Sun, 8 May 2005 00:47:05 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | I was planning to summarize home install support here, but your | statement above has confused me a little. Is there any case where a | package *must* have a dependency installed globally? If so, I can't | see it. I'm kinda inclined to say that there will be situations in which packages must have a dependency installed in either / or prefix, *not* homedir. But then, I can't think of a situation where all of the following would be true: * A package requires a (/ or prefix) install of a dep * The dep in question is capable of being installed into homedir So I think your list is good. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpU0ZOv3Ju2l.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Fri, May 06, 2005 at 02:28:49PM +0100, Ciaran McCreesh wrote: The problem isn't the packages. The problem is the ebuilds. Agreed, although seemed to take a bit of dancing to get done to the fact that yes, changing the prefix has a good chance of working. From there, we're back to the old two step econf/eclasses _do_ address a sizable portion of ebuilds in the tree ;) | Eh? No, see, we have KEYWORDS, which indicate whether you can use a | package on a given arch. | | Dodging my point. You stated, if we introduce it, people will expect | it to actually work. It's defeatist logic; won't try because people | might bitch if they wade into experimental territory and get bit. | | That's the point I was getting at, which you seemed to ignore/not | understand. | | Pointing out that people might try an experimental feature and hit | issues and bitch as a reason for _not_ doing something is just plain | daft. Except we have an easy way of marking which ebuilds will actually work with this thing. Why not use it? It's a hell of a lot cleaner, it gives us better feedback and it makes it easier for the users. Not much for a keyword route personally, since (imo) it's a slight perversion of the focus of keywords. If the keywording route was taken, would need to either duplicate existing keywords (have x86/~x86, and x86-weirdo-prefix ~x86-weirdo-prefix), or require two specific keywords being set (x86 and weirdo-prefix from the example above). I'd suspect your metadata addition (which needs a better name then ICANINSTALLTO) is the best route. Per-ebuild whitelisting, kind of like KEYWORDS. This has the added advantage of making it easy for additional kinds of install target to be added at some point. See above (agreed). | So, fink demonstration of --prefix hackery? If you want a better example, try either SGI or Sun's GNU tools ports. But they don't use ebuilds either. Well, main point was that the underlying packages _can_ swing this type of hackery for the most part, what is needed is a tweak to our ebuild conventions to allow for it. Meanwhile, iirc from the last irc conversation on this, either you or dsd brought up the point of needing to be able to query if (using vim as an example) vim-core was $home, rather then usr|$PREFIX. Care to elaborate a bit? Mainly wondering if to encompass your requests, it might require extra metadata from the depend standpoint. ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Fri, 6 May 2005 20:05:18 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| On Fri, May 06, 2005 at 02:28:49PM +0100, Ciaran McCreesh wrote:
| The problem isn't the packages. The problem is the ebuilds.
| Agreed, although seemed to take a bit of dancing to get done to the
| fact that yes, changing the prefix has a good chance of working.
|
| From there, we're back to the old two step econf/eclasses _do_ address
| a sizable portion of ebuilds in the tree ;)
More to the point, they *don't* address a sizable portion of the ebuilds
in the tree.
| Not much for a keyword route personally, since (imo) it's a slight
| perversion of the focus of keywords. If the keywording route was
| taken, would need to either duplicate existing keywords (have
| x86/~x86, and x86-weirdo-prefix ~x86-weirdo-prefix), or require two
| specific keywords being set (x86 and weirdo-prefix from the example
| above).
|
| I'd suspect your metadata addition (which needs a better name then
| ICANINSTALLTO) is the best route.
That was what I was proposing. Not KEYWORDS, a new variable. Which needs
a better name than ICANINSTALLTO.
| | So, fink demonstration of --prefix hackery?
|
| If you want a better example, try either SGI or Sun's GNU tools
| ports. But they don't use ebuilds either.
| Well, main point was that the underlying packages _can_ swing this
| type of hackery for the most part, what is needed is a tweak to our
| ebuild conventions to allow for it.
'tweak' is too mild a term... As far as I can tell I'm the only person
who's bothered to actually even try to look at this from an ebuild
perspective -- not pretty... For every package in the tree that has a
sed -e 's,/usr/local,/usr,g' there's another that would need a sed
turning /usr into whatever prefix ends up as, and it's not at all
obvious what they are. It gets even worse when you consider all the
stuff with #!/usr/bin/blah hardcoded that will need changed to use our
interpreter prefix -- these are very tricky to spot if you have a
braindead vendor-supplied interpreter in /usr/bin too.
Sure, it can be done, but not all at once, hence me screaming whitelist.
| Meanwhile, iirc from the last irc conversation on this, either you or
| dsd brought up the point of needing to be able to query if (using vim
| as an example) vim-core was $home, rather then usr|$PREFIX. Care to
| elaborate a bit? Mainly wondering if to encompass your requests, it
| might require extra metadata from the depend standpoint.
Ok, say we use ICANINSTALLTO (name!). Then if we have prefix as the
destination, there's no problem, because we know that all our deps are
installed in ${PREFIX} as well. However, if we're installing to home,
we need to know where our deps are -- for home installs I'm presuming
we don't force a full dep tree in home (unlike for prefix). This
*could* still be done with ${PREFIX} I guess? Or to avoid confusing
things, ${DEPS_PREFIX}? Not really sure...
--
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
pgpoZsJn4holG.pgp
Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Thu, May 05, 2005 at 03:48:49AM -0500, Brian Harring wrote: default being use or use/local or whatever the hell Wow. no more posting at 3:50 am... meant usr for above, pardon. ~brian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Thu, 5 May 2005 03:48:49 -0500 Brian Harring [EMAIL PROTECTED] wrote: | Ok, here's the main issue. Simply changing prefix isn't enough to | automatically make every package in the tree work. A heck of a lot | of them will need manual modification, and there's no easy way to | figure out which these are. So... | | Err. ROOT!=/ exists already, and directly screws with prefixes. So | this doesn't seem particularly valid in light of that fact. No, root doesn't screw with prefixes. | Thing is, if we introduce the PREFIX feature, people will expect it | to actually work. It won't, at least not straight away, because | there are so many ebuilds that use more than econf to get the prefix | figured out. By whitelisting we can at least display a nice you | can't install this package in a prefix message. | | Not a valid arguement to exempt even trying. | | Consider if people used that arg for avoiding porting linux to new | arches- Linux would still be strictly x86. Eh? No, see, we have KEYWORDS, which indicate whether you can use a package on a given arch. | Yet another issue... As it stands, all deps must be installed into | the given PREFIX. This is messy. Is there a way around this? This | would be less of a problem with ICANINSTALLTO=home -- presumably | for these portage could pass a var to the ebuild telling it in which | prefix to look for its deps. | | injections, mainly. Nasty hack. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpKZzkoe7eB9.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, 2 May 2005 21:48:10 -0500 Brian Harring [EMAIL PROTECTED] wrote: Clarify why portage, which _does_ function as a secondary pkg manager (collision-protect wouldn't exist otherwise) wouldn't suffice if someone gave enough of a damn to do the work? Off-topic, but collision-protect wasn't written for that purpose but to detect broken/conflicting packages. The macos project just uses it. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. pgpZhoagFR3fl.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Ciaran McCreesh wrote: Oh, and by the way, we don't follow FHS. This makes things easier, so what's better - to omit this completely, or just say (without a reference to FHS): This document prefers a filesystem hierarchy under this prefix as close as possible to the current filesystem hierarchy used in Gentoo Linux. ~haubi -- Michael HaubenwallnerSALOMON Automation GmbH Forschung Entwicklung A-8114 Friesach bei Graz mailto:[EMAIL PROTECTED] http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Monday 02 May 2005 21:22, Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... How about packages that usually install into /? Regards, Jason Stubbs pgpbBCO46FIdq.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, 2 May 2005 19:02:29 -0500 Brian Harring [EMAIL PROTECTED] wrote: | State said problem for the general community. Guessing you're | referencing the issue/request that being able to manage home, and | 'global' installations? | | I'd still posit that the issue of installing to a user's home when | portage's base prefix is /usr/local (fex) is a seperate issue. What | you were requesting for vim plugins goes beyond haubi's initial | goals... Ok, here's the main issue. Simply changing prefix isn't enough to automatically make every package in the tree work. A heck of a lot of them will need manual modification, and there's no easy way to figure out which these are. So... My suggested way around this was to have a variable in ebuilds. Call it something like ICANINSTALLTO (that name sucks, come up with something better), which defaults to ICANINSTALLTO=usr. Ebuilds which have been explicitly checked and designed by the maintainer for prefix installs get ICANINSTALLTO=usr prefix. This also allows us to do other cool stuff like ICANINSTALLTO=home, for things like vim and gkrellm plugins which can go in ~/.vim/ and ~/.gkrellm2/plugins/ respectively. Thing is, if we introduce the PREFIX feature, people will expect it to actually work. It won't, at least not straight away, because there are so many ebuilds that use more than econf to get the prefix figured out. By whitelisting we can at least display a nice you can't install this package in a prefix message. Another issue... Portage installs to /usr/local are no good, because there might be other non-portage installs there too. If we're installing to a prefix, we have to be the *only* thing installing there. No other packages, not even other manual installs. Yet another issue... As it stands, all deps must be installed into the given PREFIX. This is messy. Is there a way around this? This would be less of a problem with ICANINSTALLTO=home -- presumably for these portage could pass a var to the ebuild telling it in which prefix to look for its deps. That'll do for now. I'll shoot some more holes in it once these have been figured out. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp6wQtIw2q2O.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, 02 May 2005 14:22:15 +0200 Michael Haubenwallner [EMAIL PROTECTED] wrote: | Hi ebuild devs, | | Here's a glep draft now for (a part of) the long-term portage-goal | act as a secondary package manager ... Why did you post this without addressing the problems I pointed out to you previously? Writing something up as a GLEP doesn't magically fix all the holes in it. Oh, and by the way, we don't follow FHS. -- Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpE4zkosCpXz.pgp Description: PGP signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Jackson wrote: Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't install everything for pkg FOO in ROOT=/opt fex. Mostly useful for alt arches when /usr is taken by the primary OS and you need portage's DEPEND packages to go somewhere else. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQnbMxWzglR5RwbyYAQJR7BAAmi8n2DGmN+icAJODkYQQYhLDmK+AJe86 aGS2sp2gtVufZEIjDWixtmOvxnNb4i5WSwxHCFI3sRK0WdtshFjMOVaPDoajnnUk QAEsExe90DLiwQQN55BABjC3x5kKLhuyEpH3MYMQOrv1lGOclD3j/jRRoVgakBJF YF7o0LIEZNSeby9cqTWzBx9G+4WgLVtAFBkKc7NqvqusYuyEWr2MI7eI0D8WuEXT BZfB1uJtKbLXBbtUNbOYAxYOnGvQieKTVErlg+Of+7qsoX3fiYn9Y09ERIK5qRQ0 k4lIwZ+75bRiANvgfBQM90G87fUTgJsIuXmVhrVc0Z4L4tfIcFuVvV16w9efiY91 JVxkUCrb8ZJPI8ScIv/sPUWAkzSKYL66xtMaVhzyeT4E6ZPD7mZcNGFu4D/oNL1Z CpDlrkuIuBWTJOCz3vlG4bm4x9HWFi44ukq8bFMr0iiimPicJW+QoTpvZKhnMaSC mdy7Z/rAcsIvnwcQRgcmJeCAmQQ1xVz/h/X4AyMMApAwVAFgzFvEWC7AWnxCAGMd EVTX7D5paNA3yia9nDkEcJ1ryNhjEEQ83lFwtcRnlXNDuRQ/9bk/XzLBPXONMhye n8rK8v+xcn0bGgjG9s2wwiMSxTQWxibqY4CB0DZR43KsL+jw3MD0B34HAbTBPE19 +mxWlsBDV+U= =8uFj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, 2005-05-02 at 20:58 -0400, Alec Warner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Jackson wrote: Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't install everything for pkg FOO in ROOT=/opt fex. Mostly useful for alt arches when /usr is taken by the primary OS and you need portage's DEPEND packages to go somewhere else. Well, I've got a bug open to have a different variable like ROOT that portage would read config files from. Maybe you could jump on that bandwagon, and see if you can make things work that way. I just don't see the uptake to fix a very large portion of the tree for something that I'd guess most devs think is pointless. That's also the reason the enterprise tree hasn't taken off. People working in their free time couldn't give a crap about people thinking Gentoo isn't suitable for enterprise applications. In fact, I'd bet there are even some people that already do or would sabotage such an effort. If you want to use portage, use Gentoo. If you want some package manager for your solaris/x86 box(just an example!), go talk to the people that do openembedded. They are geared toward using it as a secondary package manager on a system. --Iggy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, May 02, 2005 at 09:11:03PM -0500, Brian Jackson wrote: Well, I've got a bug open to have a different variable like ROOT that portage would read config files from. Maybe you could jump on that bandwagon, and see if you can make things work that way. Assuming you're referencing CONFIG_ROOT, it frankly isn't much of a solution for his needs. The problem with CONFIG_ROOT is you would have to set it for every emerge invocation. His intention is to have portage function from a variable prefix, and install to a build time defined prefix. IOW, portage using different paths on an installed box, not portage installed to it's normal location, and hacked up via an environment variable to try and change the behaviour. I'm not much for config_root, obviously. The intention of it, and varying root (imo) is a hack around portage's expectations about it's configuration and repos. It's not much of a proper solution. I just don't see the uptake to fix a very large portion of the tree for something that I'd guess most devs think is pointless. Aparently people didn't notice the multilib changes passing through the tree the last few months? Same type of wide spread change, yet it's being done, and ebuilds are being migrated. Things break, but the party/person interested in adding the support is doing the work. Sidenote re: fixing a large portion of the tree, eclasses and portage's base template for ebuilds would be the first start in terms of changes. That 'very large' portion of the tree arguement would be ixnayed via that, what would remain is a collection of pissy packages that need manual tweaking. That's also the reason the enterprise tree hasn't taken off. People working in their free time couldn't give a crap about people thinking Gentoo isn't suitable for enterprise applications. The reason for the enterprise tree not being ready/finished, or even *accepted* (it _still_ is a draft after all) is frankly no ones fault but those who want such a tree. The reason glep25 (my own glep) isn't implemented is again, no ones fault but those pushing it (read: me). Might want to clarify what you're asserting, cause I'm not seeing the validity in it... So... yeah, the enterprise angle imo is slightly daft. If you're arguing that their are more 'important' things to do rather then this, state it as such, or please clarify... If you want to use portage, use Gentoo. That should be or put in the grunt work to support it. If I recall correctly, you're working on gentoo embedded. The arguements you're leveling above could just as easily be used against expanding the tree to support uclibc, or a slightly saner example, dropping osx support (portage _is_ the secondary manager there). Hell, y'all are in a similar boat, for actual device updating you'll be using emerge.c, which _isn't_ portage, just compatible with the binpkg support. Either way, my point is that portage/gentoo will flow into the niche's people care to expand it into. It's pointless telling them not to do it, because they _will_ do it anyways if it makes sense to them. So point out the failings, or better solutions. Yeah, time for me to step down from the soapbox I think... If you want some package manager for your solaris/x86 box(just an example!), go talk to the people that do openembedded. Clarify why portage, which _does_ function as a secondary pkg manager (collision-protect wouldn't exist otherwise) wouldn't suffice if someone gave enough of a damn to do the work? So yeah, anyone care to comment about the proposal's specifics, rather then piss off, no... ? :) ~brian pgpk97ief0kMp.pgp Description: PGP signature
