[gentoo-portage-dev] The merge of emerde with emerge

[gentoo-portage-dev] The merge of emerde with emerge

[Alpt]

[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]

Hi all,
here it is the patch to include all the emerde's features
in the portage.

The portage I've patched is this:
http://dev.gentoo.org/~ferringb/portage-cvs.tar.bz2

For those who don't know the story:
Emerde is born on Septmber 2003. It is a port of the portage for
slackware or generic distro. ( http://emerde.freaknet.org )

In the while I've added various handy features.
These are the additional features added in emerde:
tgz support:	A  tgzfile must be a Slackware pkg. Emerde will resolve the 
		tgz's dependences and will install it.
pfile:		Emerde will apply the specified action to all the packages listed in 
		the pfile
invulnerable:	Updates all the packages which have suid binaries.
slack-etc-update:
		Slackware configuration file updates handler.
maketgz:	Emerde will build  Slackware's  tgz packages for all ebuilds processed.
quicksearch:	The cp_all function in Emerde is rewritten to use /var/cadb, there's a 
		significant improvement in all the functions that use cp_all (--search, 
		sync, update cache etc...)
skipit:		Emerde allows you to skip to the next merge with the SIGINT signal or by 
		pressing CTRL+c.
Compilation resume:
		Emerde resumes an interrupted or aborted compilation without rebuild
		the pkg and restart the compilation.
LAN-sync:	The syncing of the portage can be done using another machine that had 
		already done it. See ACTION:sync in the emerge(1) man page.
--searchcontents:
		Emerde matches the search string against the contents field. The pkg's 
	 	contents field  contains  a  list  of files  and  directories  installed.
		This  option is useful to know to what pkg a file or a directory belong.
--showcontents: This option is the same as the --search one except that it shows  all the
		contents file of the searched packages.
--searchinstalled:
		It filter only installed pkg in the search result.
buildworld:	Rebuilds or updates the "world" file (/var/cache/edb/world)
por2pkg:	por2pkg converts entries in the portage's db to Slack's db entries.
pkg2por:	pkg2por converts entries in the Slack's db to portage's db entries.
pordbcheck:	Checks if the programs listed in the portage's db are really installed.
initd-cfg:	/etc/init.d editor.

If I can jump in the coding with you, I can live in peace with emerde
because all the changes will be already built in and in the near future emerde won't
be needed anymore. The goal is to make the portage distro independent.

I've tested successfully the patch. It all seems to work.

Well, it's simpler to talk with the code so I leave you with it...
you can find the patch here:
http://freaknet.org/alpt/emerde/files/emerde-dev/emerde-portage-cvs.patch.bz2

Best Regards
-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Luke-Jr]

On Wednesday 01 December 2004 5:55 pm, Alpt wrote:
> For those who don't know the story:
> Emerde is born on Septmber 2003. It is a port of the portage for
> slackware or generic distro. ( http://emerde.freaknet.org )

This doesn't make sense to me... Portage is universal enough to work on any 
other common Linux system...

>
> In the while I've added various handy features.
> These are the additional features added in emerde:
> tgz support: A  tgzfile must be a Slackware pkg. Emerde will resolve the
>   tgz's dependences and will install it.

Shouldn't be part of Portage. Portage handles ebuilds, not Slackware packages.

> pfile:  Emerde will apply the specified action to all the packages listed
> in the pfile

emerge $(cat pfile)

> invulnerable: Updates all the packages which have suid binaries.

What is the purpose behind this? Some kind of bad idea to assume that suid 
packages are the only ones with security holes and updates are solely to fix 
them?

> maketgz: Emerde will build  Slackware's  tgz packages for all ebuilds

A better idea would be to convert GRPs to Slackware tgz

> skipit:  Emerde allows you to skip to the next merge with the SIGINT signal
> or by pressing CTRL+c.

There's usually an order for a reason. Usually, when I press Ctrl-C, I want 
emerge to stop altogether.

> Compilation resume:
>   Emerde resumes an interrupted or aborted compilation without rebuild
>   the pkg and restart the compilation.

Portage already does this for me.

> LAN-sync: The syncing of the portage can be done using another machine that
> had already done it. See ACTION:sync in the emerge(1) man page.

See SYNC in /etc/make.conf.example

> --searchcontents:
>   Emerde matches the search string against the contents field. The pkg's
>    contents field  contains  a  list  of files  and  directories 
> installed. This  option is useful to know to what pkg a file or a directory
> belong. --showcontents: This option is the same as the --search one except
> that it shows  all the contents file of the searched packages.

qpkg /path/to/file, no?

> buildworld: Rebuilds or updates the "world" file (/var/cache/edb/world)

There's scripts to do this, though these will always be inaccurate hacks, 
since you cannot really rebuild the world file. Also note, it's 
in /var/lib/portage/world now

> por2pkg: por2pkg converts entries in the portage's db to Slack's db
> entries. pkg2por: pkg2por converts entries in the Slack's db to portage's
> db entries. pordbcheck: Checks if the programs listed in the portage's db
> are really installed.

Doesn't belong in a package manager.

> initd-cfg: /etc/init.d editor. 

Doesn't belong in a package manager.

>
> If I can jump in the coding with you, I can live in peace with emerde
> because all the changes will be already built in and in the near future
> emerde won't be needed anymore. The goal is to make the portage distro
> independent.

Portage is already distro-independent... The only distros to have considered 
using it (Zynot and Utopios) both determined that it would be better to write 
a better package manager based on the ideas.
OpenEmbedded modified Portage a bit, but needed too many features added to 
stay compatible with ebuilds.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Alpt]

On Wed, Dec 01, 2004 at 07:22:56PM +0000, Luke-Jr after a spiritual call wrote  :
~> On Wednesday 01 December 2004 5:55 pm, Alpt wrote:
~> > For those who don't know the story:
~> > Emerde is born on Septmber 2003. It is a port of the portage for
~> > slackware or generic distro. ( http://emerde.freaknet.org )
~> 
~> This doesn't make sense to me... Portage is universal enough to work on any 
~> other common Linux system...

okey, install it in slackware then and use it. let me see please.

~> > In the while I've added various handy features.
~> > These are the additional features added in emerde:
~> > tgz support: A  tgzfile must be a Slackware pkg. Emerde will resolve the
~> >   tgz's dependences and will install it.
~> 
~> Shouldn't be part of Portage. Portage handles ebuilds, not Slackware packages.

It is to let emerde live peacefull in Slackware.

~> > pfile:  Emerde will apply the specified action to all the packages listed
~> > in the pfile
~> 
~> emerge $(cat pfile)

emerde pfile pfile

;)

~> > invulnerable: Updates all the packages which have suid binaries.
~> 
~> What is the purpose behind this? Some kind of bad idea to assume that suid 
~> packages are the only ones with security holes and updates are solely to fix 
~> them?

no, obviously it isn't vital but it is usefull in some cases.

~> > maketgz: Emerde will build  Slackware's  tgz packages for all ebuilds
~> 
~> A better idea would be to convert GRPs to Slackware tgz

Slackware compatibility dude.

~> > skipit:  Emerde allows you to skip to the next merge with the SIGINT signal
~> > or by pressing CTRL+c.
~> 
~> There's usually an order for a reason. Usually, when I press Ctrl-C, I want 
~> emerge to stop altogether.

Yep, but let's assume we are doing "emerde pfile pfile" or in your case
"emerde `pfile`". If you want to skip the current merging you have to
stop emerge, modify the pfile and again "emerde pfile pfile".
It isn't very pretty when you have a list of 50 pkgs and you are arrived
at 50% in the list and you are _not_ doing --update.

~> > Compilation resume:
~> >   Emerde resumes an interrupted or aborted compilation without rebuild
~> >   the pkg and restart the compilation.
~> 
~> Portage already does this for me.

no, if halt the compilation and the next time ./configure will be runned
so you'll start the compilation again.

~> > LAN-sync: The syncing of the portage can be done using another machine that
~> > had already done it. See ACTION:sync in the emerge(1) man page.
~> 
~> See SYNC in /etc/make.conf.example

LAN-sync is: rsync -e mymachine:/usr/portage/ /usr/portage/
you can't do it right now...

~> > --searchcontents:
~> qpkg /path/to/file, no?

emerde -N /path/to/file, no?

~> > buildworld: Rebuilds or updates the "world" file (/var/cache/edb/world)
~> 
~> There's scripts to do this, though these will always be inaccurate hacks, 
~> since you cannot really rebuild the world file.

okey.

~> > por2pkg: por2pkg converts entries in the portage's db to Slack's db
~> > entries. pkg2por: pkg2por converts entries in the Slack's db to portage's
~> > db entries. pordbcheck: Checks if the programs listed in the portage's db
~> > are really installed.
~> 
~> Doesn't belong in a package manager.

Slack compat.

~> > initd-cfg: /etc/init.d editor. 
~> 
~> Doesn't belong in a package manager.

you are managing the init.d files of the packages installed with the
package manager

~> Portage is already distro-independent... The only distros to have considered 
~> using it (Zynot and Utopios) both determined that it would be better to write 
~> a better package manager based on the ideas.

Install it in the other distro then. Did you considered for example
baselayout?

regards
-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Colin Kingsley]

On Wed, 1 Dec 2004 19:22:56 +0000, Luke-Jr <luke-jr@utopios.org> wrote:
> On Wednesday 01 December 2004 5:55 pm, Alpt wrote:
> > For those who don't know the story:
> > Emerde is born on Septmber 2003. It is a port of the portage for
> > slackware or generic distro. ( http://emerde.freaknet.org )
> 
> This doesn't make sense to me... Portage is universal enough to work on any
> other common Linux system...

[..snip..]

> Portage is already distro-independent... The only distros to have considered
> using it (Zynot and Utopios) both determined that it would be better to write
> a better package manager based on the ideas.

hmmm.... So portage is universal enough, yet other distro's have
decided to write their own package manager? One of which, you are a
developer for (according to your sig)? Maybe its worth listening to
this guy, or at least not shooting him down without a second thought.
Especially since he actually has a patch and some nice things to say,
instead of the standard useless complaints.

> > In the while I've added various handy features.
> > These are the additional features added in emerde:
> > tgz support: A  tgzfile must be a Slackware pkg. Emerde will resolve the
> >   tgz's dependences and will install it.
> 
> Shouldn't be part of Portage. Portage handles ebuilds, not Slackware packages.

I was under the impression that support for third party packages was
in the works for portage? If so, dep resolution for a .tgz would be
quite handy. Am I wrong?

> 
> > pfile:  Emerde will apply the specified action to all the packages listed
> > in the pfile
> 
> emerge $(cat pfile)

Stop being pedantic. Clearly, the point of this function is to make it
easy to perform actions on large groups of packages without shell
magic.

> > maketgz: Emerde will build  Slackware's  tgz packages for all ebuilds
> 
> A better idea would be to convert GRPs to Slackware tgz

How would this be any different? or better? I'd say the ability to
create, as well as install third party packages is kind of nifty. Why
would it be better to convert a Gentoo package instead of natively
creating the .tgz?

> > Compilation resume:
> >   Emerde resumes an interrupted or aborted compilation without rebuild
> >   the pkg and restart the compilation.
> 
> Portage already does this for me.

No it doesn't. He means that a compile would be resumed from where
ever it left off, as if you were doing ./configure && make && make
install  style compilation. Currently, portage will pick up from the
beginning of the package that was being compiled when it died.

>> por2pkg: por2pkg converts entries in the portage's db to Slack's db
>> entries. pkg2por: pkg2por converts entries in the Slack's db to portage's
>> db entries. pordbcheck: Checks if the programs listed in the portage's db
>> are really installed.

>Doesn't belong in a package manager.

No? Then where would a tool to manipulate _package_ databases belong?


Colin

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Wed, 1 Dec 2004 19:22:56 +0000 Luke-Jr <luke-jr@utopios.org> wrote:
| Portage is already distro-independent...

No no no. ebuild.sh is pretty much distro independent. Portage isn't.

| The only distros to have considered using it (Zynot and Utopios) both
| determined that it would be better to write a better package manager
| based on the ideas.

Heh. Do Zynot or Utopios have anything *except* ideas? No, didn't think
so.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Luke-Jr]

On Wednesday 01 December 2004 8:51 pm, Alpt wrote:
> On Wed, Dec 01, 2004 at 07:22:56PM +0000, Luke-Jr wrote  :
> > On Wednesday 01 December 2004 5:55 pm, Alpt wrote: 
> > > Emerde is born on Septmber 2003. It is a port of the portage for
> > > slackware or generic distro. ( http://emerde.freaknet.org )
> >
> > This doesn't make sense to me... Portage is universal enough to work on
> any ~> other common Linux system...
>
> okey, install it in slackware then and use it. let me see please.

There's no purpose. If you want to use Portage, you might as well use Gentoo. 
I see no reason why it shouldn't work, though.

>
> > > In the while I've added various handy features.
> > > These are the additional features added in emerde:
> > > tgz support: A  tgzfile must be a Slackware pkg. Emerde will resolve
> > >  the tgz's dependences and will install it.
> ~>
> ~> Shouldn't be part of Portage. Portage handles ebuilds, not Slackware
> packages.
>
> It is to let emerde live peacefull in Slackware.

Inject stuff. I don't see RPM installing DEB, tgz, or ebuilds.

> > > maketgz: Emerde will build  Slackware's  tgz packages for all ebuilds
> >
> > A better idea would be to convert GRPs to Slackware tgz
>
> Slackware compatibility dude.

You're saying Portage isn't Slackware compatible because you define Slackware 
to be non-Portage.

>
> > > Compilation resume:
> > >   Emerde resumes an interrupted or aborted compilation without rebuild
> > >   the pkg and restart the compilation.
> >
> > Portage already does this for me.
>
> no, if halt the compilation and the next time ./configure will be runned
> so you'll start the compilation again.

Nope... In fact, I can change my USE and it will still output the same stuff 
since it doesn't recompile anything. A bug, but it doesn't annoy me enough.

> > > initd-cfg: /etc/init.d editor.
> >
> > Doesn't belong in a package manager.
>
> you are managing the init.d files of the packages installed with the
> package manager

Shall we include editors for all the other possible configuration files 
Portage packages install too?

>
> ~> Portage is already distro-independent... The only distros to have
> considered ~> using it (Zynot and Utopios) both determined that it would be
> better to write ~> a better package manager based on the ideas.
>
> Install it in the other distro then. Did you considered for example
> baselayout?

Inject baselayout.

On Wednesday 01 December 2004 9:14 pm, Colin Kingsley wrote:
> > Portage is already distro-independent... The only distros to have
> > considered using it (Zynot and Utopios) both determined that it would be
> > better to write a better package manager based on the ideas.
>
> hmmm.... So portage is universal enough, yet other distro's have
> decided to write their own package manager?

It'll work on systems w/o any changes, but that doesn't mean it works well. 
There are numerous flaws in the design of Portage that cannot simply be 
"fixed."

> > > Compilation resume:
> > >   Emerde resumes an interrupted or aborted compilation without rebuild
> > >   the pkg and restart the compilation.
> > 
> > Portage already does this for me.
> 
> No it doesn't. He means that a compile would be resumed from where
> ever it left off, as if you were doing ./configure && make && make
> install  style compilation. Currently, portage will pick up from the
> beginning of the package that was being compiled when it died.

Continues from where it left off for me. Possibly related to keeptemp or 
keepwork.


> >> por2pkg: por2pkg converts entries in the portage's db to Slack's db
> >> entries. pkg2por: pkg2por converts entries in the Slack's db to portage's
> >> db entries. pordbcheck: Checks if the programs listed in the portage's db
> >> are really installed.
> 
> >Doesn't belong in a package manager.
> 
> No? Then where would a tool to manipulate _package_ databases belong?

Same place as app-arch/alien
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Alpt]

On Wed, Dec 01, 2004 at 10:37:22PM +0000, Luke-Jr after a spiritual call wrote  :
~> > okey, install it in slackware then and use it. let me see please.
~> 
~> There's no purpose. If you want to use Portage, you might as well use Gentoo. 
~> I see no reason why it shouldn't work, though.

portage != Gentoo. Or am I wrong?
There are plenty of reason... they are even too obvious

~> > > > tgz support: A  tgzfile must be a Slackware pkg. Emerde will resolve
~> > > >  the tgz's dependences and will install it.
~> 
~> Inject stuff. I don't see RPM installing DEB, tgz, or ebuilds.
...
~> You're saying Portage isn't Slackware compatible because you define Slackware 
~> to be non-Portage.

the tgz support means that if you install a tgz with emerde, you'll have
all the dep checking using the pordb. It's very useful to manage the
tgzs. They don't have dependences checking. So, if you install emerde in
Slackware it's welcomed. 
This is the same for rpm, and deb. Having a unified packet manager isn't
a bad idea. Moreover the tgz/deb/rpm are binary pkg, so they can be used
if the user doesn't want to compile. 
(i'm not saying it's good to don't compile)

~> Nope... In fact, I can change my USE and it will still output the same stuff 
~> since it doesn't recompile anything. A bug, but it doesn't annoy me enough.
????
In the current portage every time src_compile is called, econf is
called, so ./configure is called again, and then make will start from
the very first source!

~> > > > initd-cfg: /etc/init.d editor.
~> > >
~> > > Doesn't belong in a package manager.
~> >
~> > you are managing the init.d files of the packages installed with the
~> > package manager
~> 
~> Shall we include editors for all the other possible configuration files 
~> Portage packages install too?

So, Do we need ufed? No, we don't cause it's so simply to live without
it.
Did you actually see initd-cfg?

~> > ~> Portage is already distro-independent... The only distros to have
~> > considered ~> using it (Zynot and Utopios) both determined that it would be
~> > better to write ~> a better package manager based on the ideas.
~> >
~> > Install it in the other distro then. Did you considered for example
~> > baselayout?
~> 
~> Inject baselayout.
It's not so simple.
You have to install rc-scripts for example. (but you don't have to install it
completely.)

~> On Wednesday 01 December 2004 9:14 pm, Colin Kingsley wrote:
~> > > Portage is already distro-independent... The only distros to have
~> > > considered using it (Zynot and Utopios) both determined that it would be
~> > > better to write a better package manager based on the ideas.
~> >
~> > hmmm.... So portage is universal enough, yet other distro's have
~> > decided to write their own package manager?
~> 
~> It'll work on systems w/o any changes, but that doesn't mean it works well. 
~> There are numerous flaws in the design of Portage that cannot simply be 
~> "fixed."

"that doesn't mean it works well" == "it messes up the system"
So you are saying that the portage is cursed to be in the eternity
blinded with gentoo. nice.

~> > No it doesn't. He means that a compile would be resumed from where
~> > ever it left off, as if you were doing ./configure && make && make
~> > install  style compilation. Currently, portage will pick up from the
~> > beginning of the package that was being compiled when it died.
~> 
~> Continues from where it left off for me. Possibly related to keeptemp or 
~> keepwork.

read above ^

ah, I forgot to say that there's also this:
The E_INFODIR, E_LOCALSTATEDIR, E_MANDIR, E_SYSCONFDIR, E_DATADIR options was added
in make.conf. With these the user can choose the destination dirs of thepackages 
being installed.

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Luke-Jr]

On Wednesday 01 December 2004 11:12 pm, Alpt wrote:
> ~> Nope... In fact, I can change my USE and it will still output the same
> stuff ~> since it doesn't recompile anything. A bug, but it doesn't annoy
> me enough. ????
> In the current portage every time src_compile is called, econf is
> called, so ./configure is called again, and then make will start from
> the very first source!

I'm not sure whether configure reruns or not, but that really doesn't matter. 
For most packages, rerunning configure does *not* require recompiling every 
file.
It's possible that the behavior I am seeing only happens when a compile 
*completes*, though.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] Re: The merge of emerde with emerge

[Dennis Bliefernicht]

Alpt wrote:
> Yep, but let's assume we are doing "emerde pfile pfile" or in your case
> "emerde `pfile`". If you want to skip the current merging you have to
> stop emerge, modify the pfile and again "emerde pfile pfile".
> It isn't very pretty when you have a list of 50 pkgs and you are arrived
> at 50% in the list and you are _not_ doing --update.

What about emerge --resume --skipfirst in this case? Does quite the 
thing you want to do here :)

Greetz
TriPhoenix


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: The merge of emerde with emerge

[Colin Kingsley]

On Thu, 02 Dec 2004 01:26:14 +0100, Dennis Bliefernicht wrote:
> What about emerge --resume --skipfirst in this case? Does quite the
> thing you want to do here :)

No it doesn't.

--resume restarts an aborted or failed merge, but it starts it at the
_beginning_ of the last package being worked on. All compilation of
that package must be repeated.

--skipfirst just skips the first package to be merged during a
--resume. It is only there so that when one package has compile
problems you can ignore it instead of actualy fixing them.

Colin

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: The merge of emerde with emerge

[Nicholas Jones]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

> --resume restarts an aborted or failed merge, but it starts it at the
> _beginning_ of the last package being worked on. All compilation of
> that package must be repeated.

Is there a good reason a compile should resume in the middle?
For what legitmate and safe reasons can you support this?

I have explicitly rejected this many times because there are
no realistic reasons to support potentially broken builds. If
the compile fails, it probably isn't a singularity within that
one file upon which it failed.

Developers, of whom there is the knowledge of 'ebuild', can work
around the restarting from the beginning issue.

--NJ



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Re: The merge of emerde with emerge

[Colin Kingsley]

> Is there a good reason a compile should resume in the middle?
> For what legitmate and safe reasons can you support this?
> 
> I have explicitly rejected this many times because there are
> no realistic reasons to support potentially broken builds. If
> the compile fails, it probably isn't a singularity within that
> one file upon which it failed.
> 
> Developers, of whom there is the knowledge of 'ebuild', can work
> around the restarting from the beginning issue.

I competely agree. I didnt mean to suggest that the current behavior
was in any way bar/wrong/incorrect. I was simply explaining how things
work. Sorry if that wasnt clear

Colin

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Nicholas Jones]

[-- Attachment #1: Type: text/plain, Size: 4458 bytes --]

> tgz support:	A  tgzfile must be a Slackware pkg. Emerde will resolve the 
> 		tgz's dependences and will install it.

If '.tgz' has been reserved for slackware, that's a bit of a
problem. The following suggestion requires some changes in portage,
but they are on the way. I'd prefer if it detected the slackware
info within the file. Portage should be able to handle any tarball
given, regardless of it's metadata format. The reason I say the
reservation is a problem stems from wanting xpaks on tgz files
instead of restricting ourselves to tbz2 which is computationally
intensive.

> pfile:  Emerde will apply the specified action to all the
>         packages listed in the pfile

I don't know what this means.

> invulnerable:	Updates all the packages which have suid binaries.

Why?

> slack-etc-update: Slackware configuration file updates handler.

Ok.

> maketgz:  Emerde will build Slackware's tgz packages for all
>           ebuilds processed.

Converting to an outside format, while good to be able to do,
is better served in an outside application. You had mentioned
in another message por2pkg or something like that. These would
be in the package to which I am refering.

> quicksearch:  The cp_all function in Emerde is rewritten to use
>               /var/cadb, there's a significant improvement in all
>               the functions that use cp_all (--search, sync,
>               update cache etc...)

What is cadb? 'esearch' and it's friends compile the data into a
db it uses to query from. The problem with portage's search is a
locality problem. Seeks on disks are a major penalty. What benefit
are you providing here?

> skipit:  Emerde allows you to skip to the next merge with the
>          SIGINT signal or by pressing CTRL+c.

This probably isn't a good idea. It's liable to break 'automatic'
configurations that the ebuild expects to be satisfied in a
particular way. Do you use this often?

> Compilation resume: Emerde resumes an interrupted or aborted
>                     compilation without rebuild the pkg and
>                     restart the compilation.

I commented on this elsewhere.

> LAN-sync:  The syncing of the portage can be done using another
>            machine that had already done it. See ACTION:sync in
>            the emerge(1) man page.

You can share your portage tree via NFS and 'emerge metadata'.
What does this gain you beyond that?

> --searchcontents:  Emerde matches the search string against the
>                    contents field. The pkg's contents field
>                    contains a list of files and directories
>                    installed. This  option is useful to know to
>                    what pkg a file or a directory belong.

External apps do this for us now. See 'etcat -b' and 'qpkg -f'.

> --showcontents: This option is the same as the --search one except
>                 that it shows all the contents file of the searched
>                 packages.

What's the use/benefit of this?

> --searchinstalled: It filter only installed pkg in the search result.

The idea is good. The number of flags that could be used here 
might be a problem though. Perhaps it's time we support '=' in
arguments:

--search=description,installed,available,masked
or something to that effect might be more effective.

> buildworld:	Rebuilds or updates the "world" file (/var/cache/edb/world)

/usr/lib/portage/bin/regenworld

> por2pkg: converts entries in the portage's db to Slack's db entries.
> pkg2por: converts entries in the Slack's db to portage's db entries.

Commented earlier.

> pordbcheck: Checks if the programs listed in the portage's db are
>             really installed.

I know that qpkg can do this. I'm not overly fond of qpkg as it's
in bash and generally annoying to fix.

> initd-cfg:	/etc/init.d editor.

Explanation would be nice... What exactly is it editing?

> If I can jump in the coding with you, I can live in peace
> with emerde because all the changes will be already built
> in and in the near future emerde won't be needed anymore.
> The goal is to make the portage distro independent.

I've got no problem with more help, but as with everyone else,
we need to look over what you've done, and how you've done it
before bringing you on board.

I'll be looking over everything at some point.
Just have to find the time.

--NJ


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Re: The merge of emerde with emerge

[Alpt]

On Wed, Dec 01, 2004 at 08:49:04PM -0500, Nicholas Jones after a spiritual call wrote  :
~> > --resume restarts an aborted or failed merge, but it starts it at the
~> > _beginning_ of the last package being worked on. All compilation of
~> > that package must be repeated.
~> 
~> Is there a good reason a compile should resume in the middle?
~> For what legitmate and safe reasons can you support this?

yes, the compiling of xfree, its aborting and its rebirth.

with the compilation resume it was added the --fclean option that force
the cleaning at the start to begin from the start.

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

On Wednesday 01 December 2004 22:14, Colin Kingsley wrote:
> >
> > emerge $(cat pfile)
>
> Stop being pedantic. Clearly, the point of this function is to make it
> easy to perform actions on large groups of packages without shell
> magic.

What's wrong with shell magic? It defines unix. Gentoo is not in the 
business of making MsWormOS

> > A better idea would be to convert GRPs to Slackware tgz
>
> How would this be any different? or better? I'd say the ability to
> create, as well as install third party packages is kind of nifty. Why
> would it be better to convert a Gentoo package instead of natively
> creating the .tgz?

Converting .tbz2 packages means that the problems are split up. In a 
future modular portage, tgz, deb, rpm, etc. creation could be performed 
by modules. Until that time, I think it should happen externally.

>
> > > Compilation resume:
> > >   Emerde resumes an interrupted or aborted compilation without
> > > rebuild the pkg and restart the compilation.
> >
> > Portage already does this for me.
>
> No it doesn't. He means that a compile would be resumed from where
> ever it left off, as if you were doing ./configure && make && make
> install  style compilation. Currently, portage will pick up from the
> beginning of the package that was being compiled when it died.

There is a reason that ./configure is rerun. Also most packages have nice 
makefiles  that do not recompile the parts that have been missing. For 
this you do indeed need the ebuild tool as there is no guarantee that it 
is actually safe.

> No? Then where would a tool to manipulate _package_ databases belong?

In a slackware specific wrapper package that wraps around portage such 
that it gets more slack compatibility. Such a package would also ensure 
that the core packages do not come from the gentoo tree, but from 
slackware.

Paul

ps. I myself consider running hybrid distributions dangerous.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Alpt]

[-- Attachment #1: Type: text/plain, Size: 7608 bytes --]

On Wed, Dec 01, 2004 at 09:15:16PM -0500, Nicholas Jones after a spiritual call wrote  :
~> If '.tgz' has been reserved for slackware, that's a bit of a
~> problem. The following suggestion requires some changes in portage,
~> but they are on the way. I'd prefer if it detected the slackware
~> info within the file. Portage should be able to handle any tarball
~> given, regardless of it's metadata format. The reason I say the
~> reservation is a problem stems from wanting xpaks on tgz files
~> instead of restricting ourselves to tbz2 which is computationally
~> intensive.

The .tgz of Slackware doesn't keep information as the .tbz2 does.
A tgz pkg is the image tar.gzipped with a doinst.sh script used to
recreate the links. Btw, the installation is held by installpkg (it
comes from pkgutil in Slackware).
The changes in emerge permit to use the portage's db to check
dependecies. When a dep is found it searches the relative .tgz in the 
specified PKGROOT, if it isn't found it merge the dep from the portage
itself.

~> > pfile:  Emerde will apply the specified action to all the
~> >         packages listed in the pfile
~> 
~> I don't know what this means.

it loads the list of pkg to consider from a file (pfile) instead from
the command line.

~> > invulnerable:	Updates all the packages which have suid binaries.
~> Why?

If the user wants to update all the suid binaries here it is.

~> > maketgz:  Emerde will build Slackware's tgz packages for all
~> >           ebuilds processed.
~> 
~> Converting to an outside format, while good to be able to do,
~> is better served in an outside application. You had mentioned
~> in another message por2pkg or something like that. These would
~> be in the package to which I am refering.

por2pkg is used to convert the portage's vardb entry to the Slackware's one
(/var/log/packages/)

~> > quicksearch:  The cp_all function in Emerde is rewritten to use
~> >               /var/cadb, there's a significant improvement in all
~> >               the functions that use cp_all (--search, sync,
~> >               update cache etc...)
~> 
~> What is cadb? 'esearch' and it's friends compile the data into a
~> db it uses to query from. The problem with portage's search is a
~> locality problem. Seeks on disks are a major penalty. What benefit
~> are you providing here?

The /var/cadb is a simple index:
[alpt@darkalpt alpt]$ cat /var/cadb
app-accessibility SphinxTrain
app-accessibility at-poke
app-accessibility brltty
...

The current cp_all function generates each time the list of
all packages... it's pretty slow because it does three nested "for" within
the listdir function. Instead in the modified version it has already the list,
so it can look up the relative category immediately.

~> > skipit:  Emerde allows you to skip to the next merge with the
~> >          SIGINT signal or by pressing CTRL+c.
~> 
~> This probably isn't a good idea. It's liable to break 'automatic'
~> configurations that the ebuild expects to be satisfied in a
~> particular way. Do you use this often?

I know, it can't be used if a dependece being processed is a must, but
it's very usefull in some case. For example where you are processing a
list of 50 pkgs without doing -u, you are in the middle of the list and
you want to skip the current pkg.

~> > Compilation resume: Emerde resumes an interrupted or aborted
~> >                     compilation without rebuild the pkg and
~> >                     restart the compilation.
~> 
~> I commented on this elsewhere.

so? what's the response?
I find it very useful, expecially when I merge a big pkg (xfree).

~> > LAN-sync:  The syncing of the portage can be done using another
~> >            machine that had already done it. See ACTION:sync in
~> >            the emerge(1) man page.
~> 
~> You can share your portage tree via NFS and 'emerge metadata'.
~> What does this gain you beyond that?

it's cool ;) You don't have to use NFS, but only your shell account.
It might be more comfortable.
that's all.

~> > --searchcontents:  Emerde matches the search string against the
~> >                    contents field. The pkg's contents field
~> >                    contains a list of files and directories
~> >                    installed. This  option is useful to know to
~> >                    what pkg a file or a directory belong.
~> 
~> External apps do this for us now. See 'etcat -b' and 'qpkg -f'.

it shouldn't be an external app feature. If I have the portage I want to
use only it.

~> > --showcontents: This option is the same as the --search one except
~> >                 that it shows all the contents file of the searched
~> >                 packages.
~> 
~> What's the use/benefit of this?

you haven't to find the relative category,
cd /var/db/pkg/CAT/PKG,
cat CONTENTS.

It is extremely handy when you do it often.

~> > --searchinstalled: It filter only installed pkg in the search result.
~> 
~> The idea is good. The number of flags that could be used here 
~> might be a problem though. Perhaps it's time we support '=' in
~> arguments:

It isn't mentioned but each option added has its short mapping. 
--searchinstalled == -L
--showcontents == -T
--searchcontents == -N
...

~> --search=description,installed,available,masked
~> or something to that effect might be more effective.
yes, but the short mapping it's lazier for the laziest people.

~> > buildworld:	Rebuilds or updates the "world" file (/var/cache/edb/world)
~> 
~> /usr/lib/portage/bin/regenworld
okay.

~> > pordbcheck: Checks if the programs listed in the portage's db are
~> >             really installed.
~> 
~> I know that qpkg can do this. I'm not overly fond of qpkg as it's
~> in bash and generally annoying to fix.

I created pordbcheck because in other distro from Slackware, emerde
installs a prebuild /var/db/pkg.

btw, I'd like to do something to see all the installed pkg without
syncing with any pkg's db, but to do this it's necessary have the list
of files which each ebuild will generate...

~> > initd-cfg:	/etc/init.d editor.
~> 
~> Explanation would be nice... What exactly is it editing?
the initd-cfg it's like ufed; you get a list of the files in
/etc/init.d. Then you check or decheck the one you want to be
executable.
I made you a screen shot: http://hinezumilabs.org/alpt/shot-initd.png

I didn't mentioned that for emerde I use a rc.emerde to control all the
scripts in /etc/init.d. In the style of:
rc.emerde start (and it starts all the scripts executable in
/etc/init.d)
rc.emerde stop
rc.emerde restart

then there's Semerde.stop in rc.d/rc[60].d
Semerde.stop does this:
        /etc/rc.d/rc.emerde stop
	rm -f /var/lib/init.d/started/*

I didn't included them in the patch, I don't know if they can be useful
for gentoo too.

~> > If I can jump in the coding with you, I can live in peace
~> > with emerde because all the changes will be already built
~> > in and in the near future emerde won't be needed anymore.
~> > The goal is to make the portage distro independent.
~> 
~> I've got no problem with more help, but as with everyone else,
~> we need to look over what you've done, and how you've done it
~> before bringing you on board.

roger that, sir.

Best Regards
-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Brian Harring]

On Thu, 2004-12-02 at 13:49 +0100, Paul de Vrieze wrote:
> On Wednesday 01 December 2004 22:14, Colin Kingsley wrote:
> > >
> > > emerge $(cat pfile)
> >
> > Stop being pedantic. Clearly, the point of this function is to make it
> > easy to perform actions on large groups of packages without shell
> > magic.
> 
> What's wrong with shell magic? It defines unix. Gentoo is not in the 
> business of making MsWormOS
Throwing in my 2 cents on this lil ^^^ bit of nastyness, kindly save us
our sanity and avoid the fud.

Argue your point w/out resorting to it please.  Unless you're intending
on somehow linking a command line _argument_ option to ms's swiss cheese
implementations- in which case, feel free to attempt it.

I'm sure it would be a good laugh.


> > > A better idea would be to convert GRPs to Slackware tgz
> >
> > How would this be any different? or better? I'd say the ability to
> > create, as well as install third party packages is kind of nifty. Why
> > would it be better to convert a Gentoo package instead of natively
> > creating the .tgz?
> 
> Converting .tbz2 packages means that the problems are split up. In a 
> future modular portage, tgz, deb, rpm, etc. creation could be performed 
> by modules. Until that time, I think it should happen externally.
Converting introduces its own problems.  You would have to elaborate on
this statement- it's a bit vague at the moment what conversion of
alternate formats to the binpkg format would gain.

Regarding creation of rpm's, portage has had that support for a while
now (it was duct taped into ebuild.sh).


> > No? Then where would a tool to manipulate _package_ databases belong?
> 
> In a slackware specific wrapper package that wraps around portage such 
> that it gets more slack compatibility. Such a package would also ensure 
> that the core packages do not come from the gentoo tree, but from 
> slackware.
It's been stated elsewhere, but to restate it again...
portage != gentoo .

Portage *should* not impose any type of restriction as to which tree
'core' packages come from.  It's not even particularly feasible to
attempt it if you're aware of the internals.  The slack 'compatibility'
part is addressed below.

> ps. I myself consider running hybrid distributions dangerous.
Don't then, frankly.  That doesn't mean a potential direction for
portage development should be avoided.  It's potentially dangerous
mixing binpkgs in a system that's strictly src, yet users do it.

Portage is a tool, tiz up to the user if they want to shoot themselves
in the foot (another unix principle).

Back to the 'make it a wrapper' thing, for it to be external, that's not
in line with the current goals of most of the portage developers- see
genone's omecron design spec, and jstubbs compilation of portage
goals.  
Additionally, it will be a pain in the ass forcing the wrapper to
basically duplicate dependency resolution, eg, pulling from it's
tree/repository when possible, falling back to querying portage.

If it's going to be implemented, it should be implemented _in_ portage
as a specific tree type, with the format properly wrapped/abstracted.
Portage currently isn't incredibly far along in internally wrapping the
ebuild format into it's own class, but it is intended.
~brian


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Brian Harring]

On Thu, 2004-12-02 at 00:12 +0100, Alpt wrote:
> ~> Nope... In fact, I can change my USE and it will still output the same stuff 
> ~> since it doesn't recompile anything. A bug, but it doesn't annoy me enough.
> ????
> In the current portage every time src_compile is called, econf is
> called, so ./configure is called again, and then make will start from
> the very first source!

A separate src_configure phase would be useful, at least for devs.  It's
been requested, although transitioning the tree to using src_compile and
src_configure would be interesting.
~brian


--
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] Re: The merge of emerde with emerge

[Dennis Bliefernicht]

Colin Kingsley wrote:
>>What about emerge --resume --skipfirst in this case? Does quite the
>>thing you want to do here :)
> 
> No it doesn't.
> 
> --resume restarts an aborted or failed merge, but it starts it at the
> _beginning_ of the last package being worked on. All compilation of
> that package must be repeated.
> 
> --skipfirst just skips the first package to be merged during a
> --resume. It is only there so that when one package has compile
> problems you can ignore it instead of actualy fixing them.

The intention was "If you want to skip the current merging", Ctrl-C and 
emerge --resume --skipfirst does exactly that. Compilation of the 
package in progress is irrelevant as it's the package that should be 
skipped :)

Greetz
TriPhoenix


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: The merge of emerde with emerge

[Ed Grimm]

On Fri, 3 Dec 2004, Dennis Bliefernicht wrote:

> Colin Kingsley wrote:
>>>What about emerge --resume --skipfirst in this case? Does quite the
>>>thing you want to do here :)
>>
>> No it doesn't.
>>
>> --resume restarts an aborted or failed merge, but it starts it at the
>> _beginning_ of the last package being worked on. All compilation of
>> that package must be repeated.
>>
>> --skipfirst just skips the first package to be merged during a
>> --resume. It is only there so that when one package has compile
>> problems you can ignore it instead of actualy fixing them.
>
> The intention was "If you want to skip the current merging", Ctrl-C
> and emerge --resume --skipfirst does exactly that. Compilation of the
> package in progress is irrelevant as it's the package that should be
> skipped :)

I'm curious...  I have 50 packages I want to install; miraculously,
there are no unsatisfied dependencies (not that surprising if I've done
--onlydeps).  The second package decides to blow up in some spectacular,
non-aborting fashion - let's say it starts apparently re-compiling itself
repeatedly.  I abort, I restart with --resume --skipfirst.

Now, package 15 decides that it wants to run a test, which claims it's
going to take 15 hours to complete.  I abort, I restart with --resume
--skipfirst.  What package starts compiling?  2, 15, or 16?

Ed

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: The merge of emerde with emerge

[Colin Kingsley]

On Fri, 3 Dec 2004 03:45:37 +0000 (GMT), Ed Grimm
<paranoid@gentoo.evolution.tgape.org> wrote:
> I'm curious...  I have 50 packages I want to install; miraculously,
> there are no unsatisfied dependencies (not that surprising if I've done
> --onlydeps).  The second package decides to blow up in some spectacular,
> non-aborting fashion - let's say it starts apparently re-compiling itself
> repeatedly.  I abort, I restart with --resume --skipfirst.
> 
> Now, package 15 decides that it wants to run a test, which claims it's
> going to take 15 hours to complete.  I abort, I restart with --resume
> --skipfirst.  What package starts compiling?  2, 15, or 16?

Should be 16 as far as I know.


Colin

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Ed Grimm]

On Wed, 1 Dec 2004, Nicholas Jones wrote:
>> skipit:  Emerde allows you to skip to the next merge with the
>>          SIGINT signal or by pressing CTRL+c.
>
> This probably isn't a good idea. It's liable to break 'automatic'
> configurations that the ebuild expects to be satisfied in a
> particular way. Do you use this often?

If done properly, this would be very useful.  By properly, I mean that
aborting a dependency would abort all following packages that depended
upon this.  If all remaining packages are dependent upon it, this is no
change from the current behavior.  However, if many packages are
specified on the command-line, this is unlikely for the first
interruption (of course, if that's on glibc, it becomes much more
likely.)

Note that the ideal solution would not abort a future package if the
package directly aborted is a reinstall or upgrade, and the already
installed version satisfies the dependency of the future package.

Of course, it sounds like he didn't do this, from his responses to
questions about this item.  I believe that it'd require a fair amount of
work to pull it off efficiently.

Ed

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


| ah, I forgot to say that there's also this:
| The E_INFODIR, E_LOCALSTATEDIR, E_MANDIR, E_SYSCONFDIR, E_DATADIR options was
added
| in make.conf. With these the user can choose the destination dirs of thepackages
| being installed.

The EXTRA_ECONF variable currently exists for this (and anything else the user
wants to change).

EXTRA_ECONF="--infodir=... --localstatedir=... etc ..."

- --
Please keep your hands off the secretary's reproducing equipment.

Aaron Walker < ka0ttic@gentoo.org >	http://dev.gentoo.org/~ka0ttic/
Gentoo/BSD | cron | shell-tools		http://butsugenjitemple.org/~ka0ttic/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBsASFC3poscuANHARAvKJAJ44anJRIJP8wSp1r01VUxMuFFMACwCfWkg/
xLHORit6Gjlqo7KISk8C+HI=
=vBhw
-----END PGP SIGNATURE-----


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Alpt]

On Fri, Dec 03, 2004 at 04:11:54AM +0000, Ed Grimm after a spiritual call wrote  :
~> Note that the ideal solution would not abort a future package if the
~> package directly aborted is a reinstall or upgrade, and the already
~> installed version satisfies the dependency of the future package.

you can do this! ^_^ It works exactly in this way.
-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

On Thursday 02 December 2004 17:11, Brian Harring wrote:
> Back to the 'make it a wrapper' thing, for it to be external, that's
> not in line with the current goals of most of the portage developers-
> see genone's omecron design spec, and jstubbs compilation of portage
> goals.
> Additionally, it will be a pain in the ass forcing the wrapper to
> basically duplicate dependency resolution, eg, pulling from it's
> tree/repository when possible, falling back to querying portage.
>
> If it's going to be implemented, it should be implemented _in_ portage
> as a specific tree type, with the format properly wrapped/abstracted.
> Portage currently isn't incredibly far along in internally wrapping the
> ebuild format into it's own class, but it is intended.
> ~brian

At the point where there are proper modules in portage, I'm all for it to 
make everything a module. What I mean is that slack code should be 
modularized in such a way that there is no trace of it when you don't 
want it. For the current system that means some wrapper of some kind. For 
a modularized system that means that there is a slack package that 
installs a number of slackware specific modules and configures portage to 
use them.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Alpt]

On Fri, Dec 03, 2004 at 01:15:33AM -0500, Aaron Walker after a spiritual call wrote  :
~> 
~> | ah, I forgot to say that there's also this:
~> | The E_INFODIR, E_LOCALSTATEDIR, E_MANDIR, E_SYSCONFDIR, E_DATADIR options was
~> added
~> | in make.conf. With these the user can choose the destination dirs of thepackages
~> | being installed.
~> 
~> The EXTRA_ECONF variable currently exists for this (and anything else the user
~> wants to change).
~> 
~> EXTRA_ECONF="--infodir=... --localstatedir=... etc ..."

really?
then why in econf the ./configure stuff is done with absolute path?
if you pass to EXTRA_CONF --mandire for example then you'll have 
./configure --mandir /usr/share/man --mandir USER_SUPPLIED_PATH
what will happen?

anyway I think it's cleaner to keep  E_INFODIR, E_LOCALSTATEDIR,
E_MANDIR, E_SYSCONFDIR, E_DATADIR  separated from EXTRA_CONF

Regards ^_^
-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alpt wrote:
| On Fri, Dec 03, 2004 at 01:15:33AM -0500, Aaron Walker after a spiritual call
wrote  :
| ~>
| ~> | ah, I forgot to say that there's also this:
| ~> | The E_INFODIR, E_LOCALSTATEDIR, E_MANDIR, E_SYSCONFDIR, E_DATADIR
options was
| ~> added
| ~> | in make.conf. With these the user can choose the destination dirs of
thepackages
| ~> | being installed.
| ~>
| ~> The EXTRA_ECONF variable currently exists for this (and anything else the user
| ~> wants to change).
| ~>
| ~> EXTRA_ECONF="--infodir=... --localstatedir=... etc ..."
|
| really?
| then why in econf the ./configure stuff is done with absolute path?

Because those are the defaults.  They have to default to something, even if
unspecified (in that case --prefix=/usr/local iirc).

| if you pass to EXTRA_CONF --mandire for example then you'll have
| ./configure --mandir /usr/share/man --mandir USER_SUPPLIED_PATH
| what will happen?

afaik, configure will use the last specified option.  If you specify --mandir
twice, it'll use the last specified one (see for yourself).  That's probably
the reason EXTRA_ECONF is passed to configure *after* the paths.

| anyway I think it's cleaner to keep  E_INFODIR, E_LOCALSTATEDIR,
| E_MANDIR, E_SYSCONFDIR, E_DATADIR  separated from EXTRA_CONF

It's your program, so you are more than welcome to.  I just wanted to make sure
you were aware that there is already a way to do this.

Cheers
- --
Deliver yesterday, code today, think tomorrow.

Aaron Walker < ka0ttic@gentoo.org >	http://dev.gentoo.org/~ka0ttic/
Gentoo/BSD | cron | shell-tools		http://butsugenjitemple.org/~ka0ttic/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBsHLuC3poscuANHARArzXAKCA2b3FWuZWaCT3folGvcsfGm0YMACgh8WY
E9uSDTFYfiJhcjQknbPmXkc=
=j67o
-----END PGP SIGNATURE-----

--
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] Re: The merge of emerde with emerge

[Torsten Veller]

* Aaron Walker <ka0ttic@gentoo.org>:
> afaik, configure will use the last specified option.  If you specify 
> --mandir
> twice, it'll use the last specified one (see for yourself).  That's probably
> the reason EXTRA_ECONF is passed to configure *after* the paths.

EXTRA_ECONF replaces default values -- but is superseded by settings in the
ebuild (man 5 ebuild and ebuild.sh):

| --prefix=/usr \
| [...]
| --localstatedir=/var/lib \
| ${EXTRA_ECONF} \
| "$@" || die "econf failed"

see request in bug #38618
-- 
.:    Torsten Veller     |     Surprise your boss.  Get to work on time.     :.

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Brian Harring]

On Fri, 2004-12-03 at 10:01 +0100, Paul de Vrieze wrote:
> At the point where there are proper modules in portage, I'm all for it to 
> make everything a module.
It's coming down the pipe.  Obviously done when it's done, but
refactoring the tree code and moving it out of portage.py and into their
own modules is my next target after I put the finishing touchs on cache
refactoring, and contents backend refactoring (bit more then a finishing
touch on the latter- need to do integration of it).

> What I mean is that slack code should be 
> modularized in such a way that there is no trace of it when you don't 
> want it.
For using a slack repository, it's possible/viable.  For
identifcation/merging of a slack tgz, that's a different case.  Unless
portage is dynamically loading all modules in a directory (or in a
specified list), identification of the tgz will be tricky- _even_ if all
slack related code is loaded on demand, that still leaves the nasty mess
of writing hooks for modules to register functions for identification of
a format.  I honestly don't see that happening for a long while, I'd
expect identification of the various formats to be handled in portage.

>  For the current system that means some wrapper of some kind.
Define wrapper.  module wrapper, seperate binary wrapper...

>  For 
> a modularized system that means that there is a slack package that 
> installs a number of slackware specific modules and configures portage to 
> use them.
There really isn't/won't be any simple way to configure portage to be
aware of new formats on the fly (imo).  It's doable, but I disagree that
no additional formats should be supported until the code is implemented
that way- as is, we already have code in portage for handling our own
binpkg format, and for rpms.
~brian


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] The merge of emerde with emerge

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Sun, 05 Dec 2004 05:21:38 -0800
Brian Harring <ferringb@gentoo.org> wrote:

> There really isn't/won't be any simple way to configure portage to be
> aware of new formats on the fly (imo).  It's doable, but I disagree
> that no additional formats should be supported until the code is
> implemented that way- as is, we already have code in portage for
> handling our own binpkg format, and for rpms.

Just for clarification: We have code to build rpms, we don't have code
to use them.

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]