[gentoo-user] Things that can be improved

[gentoo-user] Things that can be improved

[Rafael Fernández López]

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

Hi,

	This is not flame war. I love Gentoo, and it is the distribution that
fits me perfectly, but I've been wondering this last year what things
can be improved in this wonderful distro.

	The first thing that I'd change is "etc-update" or "dispatch-conf". I'd
suggest to create some kind of tool like "dpkg-reconfigure" in Debian.
More intuitive than reading /etc files and writing them by hand that is
more probably to be mistaken when writing.

	Second thing that I'd improve is a security one. I know that "emerge"
is a very cared package, but it is a script. Suppose that someone
commits portage with a emerge failure in its code (he forgot a comma
!!)... if someone updates portage won't be able to update it again
because it will fail ever and ever again... So I suggest to have a
backuped emerge script that we are sure that worked (like the last
emerge tool that was used), and if the new emerge tool is mistaken (so
that user doesn't need to know python) only has to run "regenemerge" for
example, and will have the latest emerge working tool.

	If I have more ideas I'll tell ya.

Thanks in advance,
Rafael Fernández López.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFErrR1WFfYaTyFH8oRAkm7AJ0ekcFfFxUMZnqLfX0AFQYd0gd8WgCgnEmL
6ZxTZyAHJz7BhVtVt94BTbk=
=XISq
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[gentuxx]

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

Rafael Fernández López wrote:
> Hi,
>
>     This is not flame war. I love Gentoo, and it is the distribution
> that
> fits me perfectly, but I've been wondering this last year what things
> can be improved in this wonderful distro.
>
>     The first thing that I'd change is "etc-update" or
> "dispatch-conf". I'd
> suggest to create some kind of tool like "dpkg-reconfigure" in Debian.
> More intuitive than reading /etc files and writing them by hand that is
> more probably to be mistaken when writing.

I do agree that these tools fall slightly short of the goal - which
IMHO it to effectively "manage" config files when updating packages,
and to "dumb down" the management process.

I've noticed that a majority of the *.conf updates (especially
recently) tend to be changing the date(s) in the Gentoo copyright
notice (from 2005 -> 2006) and/or cvs document version header updates
(e.g. v1.5 to v1.6).  I typically use dispatch-conf, so maybe this is
what etc-update calls "trivial updates".  Without going into too many
specifics (since the thread wasn't started in a specific manner), one
of my pet peeves about dispatch-conf is that the new, unmodified
*.conf files take precedence.  I know there's the "merge" option, and
admittedly, I haven't quite figured out how to use that effectively.
But if a new *.conf file is presented, shouldn't/couldn't it diff the
new with the old and automatically incorporate the differences into
the new *.conf file?

More to the point, as I'm not familiar with "dpkg-reconfigure", or
debian for that matter, why not point out specific short-comings of
the existing tools?  Or propose a better approach to solving the
*.conf file management issue (philosophically or technically - i.e.
write one)?

>
>     Second thing that I'd improve is a security one. I know that
> "emerge"
> is a very cared package, but it is a script. Suppose that someone
> commits portage with a emerge failure in its code (he forgot a comma
> !!)... if someone updates portage won't be able to update it again
> because it will fail ever and ever again... So I suggest to have a
> backuped emerge script that we are sure that worked (like the last
> emerge tool that was used), and if the new emerge tool is mistaken (so
> that user doesn't need to know python) only has to run "regenemerge" for
> example, and will have the latest emerge working tool.
>
>
I don't know if this is technically a "security issue", moreso an
availability issue (which, yes, technically falls under security in
terms of confidentiality-integrity-availability, but in my mind falls
slightly outside of the umbrella).  While you present a valid concern,
I believe this is addressed by the whole masking/testing process that
is currently architected into portage.  If a portage developer managed
to leave out a comma when doing a cvs commit, it's *very* likely going
to be found before portage is moved to the stable tree.  Worst case
scenario, if something like this *were* to fall through the cracks,
grab your trusty install-CD and revert to a known-good portage
snapshot.  Between the lists/forums/announcements/wiki/etc., I'm sure
that something like this would surface /immediately/.

Just my 2¢...

>
> --
> gentux
> echo "hfouvyyAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
>
> gentux's gpg fingerprint ==> 5495 0388 67FF 0B89 1239  D840 4CF0
> 39E2 18D3 4A9E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFErsVqTPA54hjTSp4RApBDAKC9nlQd45p1UkwM8nD+WGOh+ZLewwCgrX9q
DvV9ZNnD3GQjYEtd4DeCR0w=
=sguh
-----END PGP SIGNATURE-----

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Daniel da Veiga]

On 7/7/06, Rafael Fernández López <info@maestroprogramador.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
>         This is not flame war. I love Gentoo, and it is the distribution that
> fits me perfectly, but I've been wondering this last year what things
> can be improved in this wonderful distro.
>
>         The first thing that I'd change is "etc-update" or "dispatch-conf". I'd
> suggest to create some kind of tool like "dpkg-reconfigure" in Debian.
> More intuitive than reading /etc files and writing them by hand that is
> more probably to be mistaken when writing.

This has been already discussed in the list, and a good discussion
too. There are tools that do the job better/faster for someone's
opinnion (not mine, I still like etc-update). You can choose that
tools, I don't know Debian, but I doubt a combination of all tools
mentioned at that thread would not come close to what you want.

>
>         Second thing that I'd improve is a security one. I know that "emerge"
> is a very cared package, but it is a script. Suppose that someone
> commits portage with a emerge failure in its code (he forgot a comma
> !!)... if someone updates portage won't be able to update it again
> because it will fail ever and ever again... So I suggest to have a
> backuped emerge script that we are sure that worked (like the last
> emerge tool that was used), and if the new emerge tool is mistaken (so
> that user doesn't need to know python) only has to run "regenemerge" for
> example, and will have the latest emerge working tool.
>

There are SO MANY ways to recover portage. A snapshot, a binary
package. If you run stable, its almost impossible, to say the least,
that you're gonna get a trivial error in emerge that prevents it from
running, if you run testing, still, gentoo devs are responsable people
and would not do something like that. If we count with that kind of
error, your "regenemerge" command would have to redownload and compile
python, portagem, pycrypt, gcc, glibc and a lot of other packages that
emerge depends on. You can always "quickpkg portage" once in a while,
but any portage snapshot untared at / would recover most of portage
for you.

No flames intended, I just say there are ways to do all this
already... But you still can post a feature request anytime.

-- 
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
------END GEEK CODE BLOCK------

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Richard Fish]

On 7/7/06, Rafael Fernández López <info@maestroprogramador.com> wrote:
>         The first thing that I'd change is "etc-update" or "dispatch-conf". I'd
> suggest to create some kind of tool like "dpkg-reconfigure" in Debian.

I don't know anything about dpkg-reconfigure, so I can't really comment on this.

But one thing I really do like about gentoo is that I *can* go modify
configuration files directly, without worrying about some distribution
tool clobbering my changes, or choking on something it wasn't setup to
deal with.  This is one of the things that drove me from SuSE.  I
would really object to some kind of "configuration file configurator"
app.

>         Second thing that I'd improve is a security one. I know that "emerge"
> is a very cared package, but it is a script. Suppose that someone

I think this is a non-issue.  Something like this would be found
incredibly quickly by the portage devs working in their overlay, and
they would know how to fix it.  In the worst of all possible cases, it
might theoretically make it to the ~arch users, who again, presumably
have enough experience to know how to resurrect their systems without
resorting to a live CD and re-install.

It is far more likely that you could break python (and thus portage)
from a mishandled gcc or glibc update.  But there is already a
recovery option available in this case; if you have buildpkg in your
FEATURES, you will already have a backup copy of
portage/python/gcc/glibc/everything else in $PKGDIR.  Even if portage
is broken, you can extract those tarballs to get back to a working
configuration.  Of course, this assumes that tar and bzip2
work...otherwise you are down to booting from a live CD.


One area I do think could be improved is in the update process.
Currently we have etc-update, revdep-rebuild, fix_libtool_files.sh,
eselect {opengl,gcc,binutils}, python-updater, perl-cleaner, and so
on.  Each update requires running one or more of these.  But which
ones, when, why, and in what order?  I *think* _I_ know the answers to
those questions, but I would bet most users do not.  So I think a
little more automation (or at least hand-holding) in portage to deal
with the above would be very useful.  Something like:

emerge -DNuv world
<several hours later>
Updates done.

Hmm, looks like a new version of python was installed.  You should run
python-updater to make sure all python modules are rebuilt.  Do you
want to do that now?

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Daniel da Veiga]

On 7/7/06, Richard Fish <bigfish@asmallpond.org> wrote:
> On 7/7/06, Rafael Fernández López <info@maestroprogramador.com> wrote:
> >         The first thing that I'd change is "etc-update" or "dispatch-conf". I'd
> > suggest to create some kind of tool like "dpkg-reconfigure" in Debian.
>
> I don't know anything about dpkg-reconfigure, so I can't really comment on this.
>
> But one thing I really do like about gentoo is that I *can* go modify
> configuration files directly, without worrying about some distribution
> tool clobbering my changes, or choking on something it wasn't setup to
> deal with.  This is one of the things that drove me from SuSE.  I
> would really object to some kind of "configuration file configurator"
> app.
>
> >         Second thing that I'd improve is a security one. I know that "emerge"
> > is a very cared package, but it is a script. Suppose that someone
>
> I think this is a non-issue.  Something like this would be found
> incredibly quickly by the portage devs working in their overlay, and
> they would know how to fix it.  In the worst of all possible cases, it
> might theoretically make it to the ~arch users, who again, presumably
> have enough experience to know how to resurrect their systems without
> resorting to a live CD and re-install.
>
> It is far more likely that you could break python (and thus portage)
> from a mishandled gcc or glibc update.  But there is already a
> recovery option available in this case; if you have buildpkg in your
> FEATURES, you will already have a backup copy of
> portage/python/gcc/glibc/everything else in $PKGDIR.  Even if portage
> is broken, you can extract those tarballs to get back to a working
> configuration.  Of course, this assumes that tar and bzip2
> work...otherwise you are down to booting from a live CD.
>
>
> One area I do think could be improved is in the update process.
> Currently we have etc-update, revdep-rebuild, fix_libtool_files.sh,
> eselect {opengl,gcc,binutils}, python-updater, perl-cleaner, and so
> on.  Each update requires running one or more of these.  But which
> ones, when, why, and in what order?  I *think* _I_ know the answers to
> those questions, but I would bet most users do not.  So I think a
> little more automation (or at least hand-holding) in portage to deal
> with the above would be very useful.  Something like:
>
> emerge -DNuv world
> <several hours later>
> Updates done.
>
> Hmm, looks like a new version of python was installed.  You should run
> python-updater to make sure all python modules are rebuilt.  Do you
> want to do that now?
>

That's more likely to be needed. +1

-- 
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
------END GEEK CODE BLOCK------

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Hemmann, Volker Armin]

On Friday 07 July 2006 21:22, Rafael Fernández López wrote:

> 	Second thing that I'd improve is a security one. I know that "emerge"
> is a very cared package, but it is a script. Suppose that someone
> commits portage with a emerge failure in its code (he forgot a comma
> !!)... if someone updates portage won't be able to update it again
> because it will fail ever and ever again... So I suggest to have a
> backuped emerge script that we are sure that worked (like the last
> emerge tool that was used), and if the new emerge tool is mistaken (so
> that user doesn't need to know python) only has to run "regenemerge" for
> example, and will have the latest emerge working tool.

once upon a time, there was a portage-rescue....

seems, that it is gone (why?) but you can still find it here:
http://dev.gentoo.org/~carpaski/portage_rescue/

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Things that can be improved

[dnlt0hn5ntzhbqkv51]

On Fri, 07 Jul 2006 17:12:13 -0400, Richard Fish <bigfish@asmallpond.org>  
wrote:

> On 7/7/06, Rafael Fernández López <info@maestroprogramador.com> wrote:
>>         The first thing that I'd change is "etc-update" or  
>> "dispatch-conf". I'd
>> suggest to create some kind of tool like "dpkg-reconfigure" in Debian.
>
> I don't know anything about dpkg-reconfigure, so I can't really comment  
> on this.
>
> But one thing I really do like about gentoo is that I *can* go modify
> configuration files directly, without worrying about some distribution
> tool clobbering my changes, or choking on something it wasn't setup to
> deal with.  This is one of the things that drove me from SuSE.  I
> would really object to some kind of "configuration file configurator"
> app.

Agree wholeheartedly.

I want to learn and use Linux (well, Gentoo Linux :-) )- not some  
distribution-dependent GUI(s).
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[leszek]

Le vendredi 07 juillet 2006 à 14:12 -0700, Richard Fish a écrit :
> Hmm, looks like a new version of python was installed.  You should run
> python-updater to make sure all python modules are rebuilt.  Do you
> want to do that now?
> 

The problem with this is that it break for users who put emerge in a
cron job.

It should first detect if you are in an interactive shell.



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Daniel Iliev]

Richard Fish wrote:

--snip
> It is far more likely that you could break python (and thus portage)
> from a mishandled gcc or glibc update.  But there is already a
> recovery option available in this case; if you have buildpkg in your
> FEATURES, you will already have a backup copy of
> portage/python/gcc/glibc/everything else in $PKGDIR.  Even if portage
> is broken, you can extract those tarballs to get back to a working
> configuration.  Of course, this assumes that tar and bzip2
> work...otherwise you are down to booting from a live CD.
--snip
Well, correct me if I'm wrong but it think it's not quite true.

I *think* if you have buildpkg in your FEATURES, you will
get binary packages in your $PKGDIR with the new, updated versions.
Those that you have just emerged , not the previous ones which you
would like to have backed up. Having the newly compiled packages
$PKGDIR can be exported via http server as an alias for example:
"alias /packages /usr/portage/packages"
and used as PORTAGE_BINHOST="http://192.168.0.1/packages
in /etc/make.conf on a buch of other machines. This way one doesn't
compile on every single machine but use the already compiled packages.
Very useful if you have many equal (as hardware) machines with the
same settings in "make.conf".
The only way (I'm aware of) to make a semiautomatic backup of
an already installed package is to use "qpkg"
"qpkg" is available in "app-portage/gentoolkit"


On the subject.

I would say that I like end use Gentoo for two main reasons:
1) it is a binary distro, which means optimization, customization and speed.
2) gentoo doesn't mess with MY config settings without asking if it should.
I would hate if some automated tool is ****ing MY settings without my
knowledge.

About the "damaged portage" issue...well, I agree with others who think it
is highly unlikely a damaged version to go out  and get available for
the users.

My "wish list"
1) I would like to see an implementation of "PAUSE". I mean, during most
of the emerges there is not only one package to be emerged. Some of the
packages have instructions for additional post installation steps that
the user
should take. Well, I think there should be a "FETURE", a flag to
"emerge" or
some other mechanism to tell portage to wait for confirmation if the ebuild
gives such information.
2) More control over portages verbosity. Most of the time I only need to see
the portages messages, not all the compilation stuff. The later is
interesting
to me only if the compilation fails.
3) I hate ebuilds that are rewriting variables that I have set. For
example I
couldn't find a way to compile mplayer with
"--disable-runtime-cpudetection",
many packages overwrite C(XX)FLAGS. They change "-O3" to "-O2" etc.
"Gentoo is about choices" but why this happens? My opinion is that portage
should warn about the "too aggressive setting" but to let ME chose to change
the settings or not.



-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Richard Fish]

On 7/7/06, Daniel Iliev <danny@ilievnet.com> wrote:
> Well, correct me if I'm wrong but it think it's not quite true.
>
> I *think* if you have buildpkg in your FEATURES, you will
> get binary packages in your $PKGDIR with the new, updated versions.

But previous versions are not deleted until you do an "eclean
packages".  So yeah, you need to have buildpkg in FEATURES for a while
to get a nice set of backup packages, or use quickpkg.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Lord Sauron]

On 7/7/06, Rafael Fernández López <info@maestroprogramador.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
>         This is not flame war. I love Gentoo, and it is the distribution that
> fits me perfectly, but I've been wondering this last year what things
> can be improved in this wonderful distro.

I've got a small list of personal pet peeves as well.  However,
overall Gentoo is beyond excellent.  It also gets the honour of being
the Distro I've stuck with the longest.

>         The first thing that I'd change is "etc-update" or "dispatch-conf". I'd
> suggest to create some kind of tool like "dpkg-reconfigure" in Debian.
> More intuitive than reading /etc files and writing them by hand that is
> more probably to be mistaken when writing.

Might want to include parts of dpkg in that tool.  No sense in
re-inventing the wheel, eh?

>         Second thing that I'd improve is a security one. I know that "emerge"
> is a very cared package, but it is a script. Suppose that someone
> commits portage with a emerge failure in its code (he forgot a comma
> !!)... if someone updates portage won't be able to update it again
> because it will fail ever and ever again... So I suggest to have a
> backuped emerge script that we are sure that worked (like the last
> emerge tool that was used), and if the new emerge tool is mistaken (so
> that user doesn't need to know python) only has to run "regenemerge" for
> example, and will have the latest emerge working tool.

It wouldn't have gotten off of the guy's test box I'd think.


My personal gripe is how slow emerge is on just plain old emerge-ish
things.  That we have to use things like eix to search is pathetic.
This NEVER happened in Debian.

I also am considering trying to adapt aptitude to Gentoo.  I think
aptitude is the best thing since...  anyways, I love aptitude and want
to make it portage-friendly.  Just having a command-line package
browser like aptitude in Gentoo would be awesome.

Now is the time to tell me how incredibly stupid I am for imagining
something like that.  Otherwise I might just fire up KDevelop, grab a
copy of aptitude, and start working.  I'm known to do things like
that.

>         If I have more ideas I'll tell ya.

Same here.

-- 
========== GCv3.12 ==========
GCS d-(++) s+: a? C++ UL+>++++ P+
L++ E--- W+(+++) N++ o? K? w--- O? M+
V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+
                DI+++ D+ G e* h- !r !y
========= END GCv3.12 ========

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Donnie Berkholz]

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

Lord Sauron wrote:
> My personal gripe is how slow emerge is on just plain old emerge-ish
> things.  That we have to use things like eix to search is pathetic.
> This NEVER happened in Debian.

Yeah, emerge should probably start caching this info for faster
searches. emerge overall though got a pretty solid speedup in 2.1.

> I also am considering trying to adapt aptitude to Gentoo.  I think
> aptitude is the best thing since...  anyways, I love aptitude and want
> to make it portage-friendly.  Just having a command-line package
> browser like aptitude in Gentoo would be awesome.
> 
> Now is the time to tell me how incredibly stupid I am for imagining
> something like that.  Otherwise I might just fire up KDevelop, grab a
> copy of aptitude, and start working.  I'm known to do things like
> that.

Might wanna take a look through the stuff in app-portage/ before you
start. I'm a fan of porthole.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-user] Things that can be improved

[Daniel Iliev]

Richard Fish wrote:
> On 7/7/06, Daniel Iliev <danny@ilievnet.com> wrote:
>> Well, correct me if I'm wrong but it think it's not quite true.
>>
>> I *think* if you have buildpkg in your FEATURES, you will
>> get binary packages in your $PKGDIR with the new, updated versions.
> 
> But previous versions are not deleted until you do an "eclean
> packages".  So yeah, you need to have buildpkg in FEATURES for a while
> to get a nice set of backup packages, or use quickpkg.
> 
> -Richard

Oh! But of cource! Now I see your point.
Who made me think $PKGDIR is not already containing packages!? :)

*CHEERS*

-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Zac Medico]

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

Lord Sauron wrote:
> My personal gripe is how slow emerge is on just plain old emerge-ish
> things.  That we have to use things like eix to search is pathetic.
> This NEVER happened in Debian.

emerge/portage has lots of room for improvement.  Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess.  However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch.  It's getting better, slowly but surely.

There are so many technical issues that remain to be solved in portage that it's difficult to justify spending time on problems that have already been solved in one way or another.  There many tools in existence that already do the search part pretty well.  Lots of other things still need fixing...

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

iD8DBQFErxZt/ejvha5XGaMRAqdoAKCkhZXGvhjY0T5MQY7srfZPPnbl7QCffDpr
wDenFodeIt1WEM+wwfzSo9U=
=RITY
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Zac Medico]

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

Hemmann, Volker Armin wrote:
> On Friday 07 July 2006 21:22, Rafael Fernández López wrote:
> 
>> 	Second thing that I'd improve is a security one. I know that "emerge"
>> is a very cared package, but it is a script. Suppose that someone
>> commits portage with a emerge failure in its code (he forgot a comma
>> !!)... if someone updates portage won't be able to update it again
>> because it will fail ever and ever again... So I suggest to have a
>> backuped emerge script that we are sure that worked (like the last
>> emerge tool that was used), and if the new emerge tool is mistaken (so
>> that user doesn't need to know python) only has to run "regenemerge" for
>> example, and will have the latest emerge working tool.
> 
> once upon a time, there was a portage-rescue....
> 
> seems, that it is gone (why?) but you can still find it here:
> http://dev.gentoo.org/~carpaski/portage_rescue/
> 

Look inside $PORTDIR/sys-apps/portage/files/README.RESCUE and you'll see this:

Please see http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml
for a recovery guide for a broken portage installation.

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

iD8DBQFErxcY/ejvha5XGaMRAi8xAJ92qQJwuahjZ3IQzVJdoZ9fh8QZvACcCsDc
ml2Uz4PQWYGAOClpZVhDajg=
=s4iZ
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Richard Fish]

On 7/7/06, Zac Medico <zmedico@gentoo.org> wrote:
> emerge/portage has lots of room for improvement.  Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess.  However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch.  It's getting better, slowly but surely.

/me bowes in reverence to Zac.  :-)

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Lord Sauron]

On 7/7/06, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> Lord Sauron wrote:
> > My personal gripe is how slow emerge is on just plain old emerge-ish
> > things.  That we have to use things like eix to search is pathetic.
> > This NEVER happened in Debian.
>
> Yeah, emerge should probably start caching this info for faster
> searches. emerge overall though got a pretty solid speedup in 2.1.

I have 2.1 and it does have a slight increase in speed, though nothing
compared to debian.

> > I also am considering trying to adapt aptitude to Gentoo.  I think
> > aptitude is the best thing since...  anyways, I love aptitude and want
> > to make it portage-friendly.  Just having a command-line package
> > browser like aptitude in Gentoo would be awesome.
> >
> > Now is the time to tell me how incredibly stupid I am for imagining
> > something like that.  Otherwise I might just fire up KDevelop, grab a
> > copy of aptitude, and start working.  I'm known to do things like
> > that.
>
> Might wanna take a look through the stuff in app-portage/ before you
> start. I'm a fan of porthole.

Kuroo is nice, however, portage still lacks the pure brilliance of
aptitude.  If you don't know what I'm talking about, get debian (or
something debain-based) and screw around with aptitude a bit.  The
think of how cool it'd be that you could use it over ssh without
having to use all the memory for remote desktop.  Then notice how fast
it is once you get savvy and start to really leverage it.  It's a far
superior piece of software, and I ended up using it rather than
graphical things like Adept, Synaptic, KPackage, and others.  It kills
both porthole and Kuroo, if that's what you're asking.

-- 
========== GCv3.12 ==========
GCS d-(++) s+: a? C++ UL+>++++ P+
L++ E--- W+(+++) N++ o? K? w--- O? M+
V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+
                DI+++ D+ G e* h- !r !y
========= END GCv3.12 ========
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Lord Sauron]

On 7/7/06, Zac Medico <zmedico@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lord Sauron wrote:
> > My personal gripe is how slow emerge is on just plain old emerge-ish
> > things.  That we have to use things like eix to search is pathetic.
> > This NEVER happened in Debian.
>
> emerge/portage has lots of room for improvement.  Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess.  However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch.  It's getting better, slowly but surely.

Yes, it does.  However, portage aside, it lacks something like
aptitude to really fill in the loose ends.

> There are so many technical issues that remain to be solved in portage that it's difficult to justify spending time on problems that have already been solved in one way or another.  There many tools in existence that already do the search part pretty well.  Lots of other things still need fixing...

Yeah.  Portage works, however, I think it's really in need of a large
overhaul.  If what you're saying is true, and it's really just a load
of scripts, then I really would HIGHLY suggest that you consider
beginning to make smaller helper applications in C and stuff to speed
things up.  Right now it does have one thing that I have to say is
better than Debian...  once you get used to it:  package masking.

That is something that is really quite nifty that debian lacks, but I
wouldn't say is a killer app.  I'll be on Gentoo for one reason only:
I'm obcessed with learning more about Linux, no matter how much
trouble that means I have to get myself into ; )

Perhaps if I ever become good enough at Linux and programming I'll
feel brave enough to try and help with the Portage problem...  It's
definitely a idea I'm beginning to entertain.  I may just start
looking through the sources.  Who knows?  With what limited skill I
have I may be able to cook up some of those helper applications to
speed things up!

Scripts are great, but they aren't for whole applications.  Yes, that
would be a quotable.

-- 
========== GCv3.12 ==========
GCS d-(++) s+: a? C++ UL+>++++ P+
L++ E--- W+(+++) N++ o? K? w--- O? M+
V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+
                DI+++ D+ G e* h- !r !y
========= END GCv3.12 ========
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Richard Fish]

On 7/7/06, Lord Sauron <lordsauronthegreat@gmail.com> wrote:
> Scripts are great, but they aren't for whole applications.  Yes, that
> would be a quotable.

I think (someone please correct me if I am wrong) that most of portage
is actually implemented in python.  The actual merge process is shell
script, but things like dependency resolution and so forth should be
all python.

And python is actually pretty quick.  Not nearly as fast as C, but
easily fast enough for this kind of work.  I think you would find the
biggest gains would be from using more efficient algorithms and data
storage, rather than re-implementing parts in another language.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Lord Sauron]

On 7/7/06, Richard Fish <bigfish@asmallpond.org> wrote:
> On 7/7/06, Lord Sauron <lordsauronthegreat@gmail.com> wrote:
> > Scripts are great, but they aren't for whole applications.  Yes, that
> > would be a quotable.
>
> I think (someone please correct me if I am wrong) that most of portage
> is actually implemented in python.  The actual merge process is shell
> script, but things like dependency resolution and so forth should be
> all python.

I don't speak much python.

> And python is actually pretty quick.  Not nearly as fast as C, but
> easily fast enough for this kind of work.  I think you would find the
> biggest gains would be from using more efficient algorithms and data
> storage, rather than re-implementing parts in another language.

Yeah, you're most likely right.

> -Richard
> --
> gentoo-user@gentoo.org mailing list
>
>


-- 
========== GCv3.12 ==========
GCS d-(++) s+: a? C++ UL+>++++ P+
L++ E--- W+(+++) N++ o? K? w--- O? M+
V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+
                DI+++ D+ G e* h- !r !y
========= END GCv3.12 ========
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Zac Medico]

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

Lord Sauron wrote:
> On 7/7/06, Zac Medico <zmedico@gentoo.org> wrote:
> Yeah.  Portage works, however, I think it's really in need of a large
> overhaul.  If what you're saying is true, and it's really just a load
> of scripts, then I really would HIGHLY suggest that you consider
> beginning to make smaller helper applications in C and stuff to speed
> things up.  Right now it does have one thing that I have to say is
> better than Debian...  once you get used to it:  package masking.

I understand that users are frustrated by a perceived lack of performance.  However, even though portage performance is far from optimal in many cases, I'm quite satisfied with it's performance levels in most of the ways that I use it.  Surely there's lots of room for improvement, but it's difficult to justify spending time on some types of performance enhancements when there are already plenty of things that are completely broken and in need of fixing.

> That is something that is really quite nifty that debian lacks, but I
> wouldn't say is a killer app.  I'll be on Gentoo for one reason only:
> I'm obcessed with learning more about Linux, no matter how much
> trouble that means I have to get myself into ; )
> 
> Perhaps if I ever become good enough at Linux and programming I'll
> feel brave enough to try and help with the Portage problem...  It's
> definitely a idea I'm beginning to entertain.  I may just start
> looking through the sources.  Who knows?  With what limited skill I
> have I may be able to cook up some of those helper applications to
> speed things up!
> 
> Scripts are great, but they aren't for whole applications.  Yes, that
> would be a quotable.

Well, I'm not interested in debating whether or not a particular language is suitable for a particular type of application development.  If you don't like Python, there is a package manager named Paludis that is implemented in C++ and is compatible with Portage in some ways.

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

iD8DBQFErzaw/ejvha5XGaMRAhxzAKCdVrvIvKz8xCTGQd750cd02YKzdwCggCaI
2jin+5gAX058AJopmB9hl2o=
=Tsna
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Lord Sauron]

On 7/7/06, Zac Medico <zmedico@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lord Sauron wrote:
> > On 7/7/06, Zac Medico <zmedico@gentoo.org> wrote:
> > Yeah.  Portage works, however, I think it's really in need of a large
> > overhaul.  If what you're saying is true, and it's really just a load
> > of scripts, then I really would HIGHLY suggest that you consider
> > beginning to make smaller helper applications in C and stuff to speed
> > things up.  Right now it does have one thing that I have to say is
> > better than Debian...  once you get used to it:  package masking.
>
> I understand that users are frustrated by a perceived lack of performance.  However, even though portage performance is far from optimal in many cases, I'm quite satisfied with it's performance levels in most of the ways that I use it.  Surely there's lots of room for improvement, but it's difficult to justify spending time on some types of performance enhancements when there are already plenty of things that are completely broken and in need of fixing.

Yup.  I'm not trying to flame the portage people, just point out that
it's not working as well as I know it can.

For you it might be fine, however, I'm trying to rough it out on a
tiny little IBM X40, which is nitorious for being slow.  I'm right now
trying to find my way into a dual-core turion, and it's looking like I
will be able to, but for now I'm stuck, like it or not.

Whether or not you/they fix portage isn't my problem, but it won't be
because I didn't say that it couldn't use some work.

> > That is something that is really quite nifty that debian lacks, but I
> > wouldn't say is a killer app.  I'll be on Gentoo for one reason only:
> > I'm obcessed with learning more about Linux, no matter how much
> > trouble that means I have to get myself into ; )
> >
> > Perhaps if I ever become good enough at Linux and programming I'll
> > feel brave enough to try and help with the Portage problem...  It's
> > definitely a idea I'm beginning to entertain.  I may just start
> > looking through the sources.  Who knows?  With what limited skill I
> > have I may be able to cook up some of those helper applications to
> > speed things up!
> >
> > Scripts are great, but they aren't for whole applications.  Yes, that
> > would be a quotable.
>
> Well, I'm not interested in debating whether or not a particular language is suitable for a particular type of application development.  If you don't like Python, there is a package manager named Paludis that is implemented in C++ and is compatible with Portage in some ways.

It's not unusable bad, and I have nothing *against* Python.  I just
don't know it as well as I do things like PHP, C, C++, C# (yes, I do
have a MSDN Membership) and other things.  That's all.

I was really referring to things like bash and tcsh.  They shouldn't
be used for whole applications.

-- 
========== GCv3.12 ==========
GCS d-(++) s+: a? C++ UL+>++++ P+
L++ E--- W+(+++) N++ o? K? w--- O? M+
V? PS- PE+ Y-(--) PGP- t+++ 5? X R tv-- b+
                DI+++ D+ G e* h- !r !y
========= END GCv3.12 ========
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Justin R Findlay]

On Sat, Jul 08, 2006 at 02:00:27AM +0300, Daniel Iliev wrote:
> 1) I would like to see an implementation of "PAUSE".

<ctrl>-s, <ctrl>-q seems to work for me.

> 2) More control over portages verbosity. Most of the time I only need to see
> the portages messages, not all the compilation stuff. The later is
> interesting
> to me only if the compilation fails.

In my /etc/make.conf I have:

PORTAGE_ELOG_CLASSES="info warn error log"
PORTAGE_ELOG_SYSTEM="mail syslog"
PORTAGE_ELOG_MAILURI="root@jfindlay.us"

with sys-apps/portage-2.1.1_pre2-r4.  I don't remember which version it
was introduced.  That doesn't control build verbosity but you can always
do 

# emerge {package} 1>/var/tmp/portage/emerge.out
2>/var/tmp/portage/emerge.err

or something like that.  If you tell it to, portage will log every last
configure and gcc statement spewed forth on the command line into
/var/log/portage/.

> 3) I hate ebuilds that are rewriting variables that I have set. For
> example I
> couldn't find a way to compile mplayer with
> "--disable-runtime-cpudetection",
> many packages overwrite C(XX)FLAGS. They change "-O3" to "-O2" etc.
> "Gentoo is about choices" but why this happens? My opinion is that portage
> should warn about the "too aggressive setting" but to let ME chose to change
> the settings or not.

Gentoo generally overwrites C(XX)FLAGS only when they are problematic
(unpredictable or cause breakage) for certain platforms/packages.  If
you have a customized ebuild you can always drop it into your own
overlay.  Mine is in /usr/local/portage.  If you have multiple overlays
you can use gensync from the gentoolkit-dev package to sync with them.


Justin
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Hemmann, Volker Armin]

On Saturday 08 July 2006 04:23, Zac Medico wrote:
>
> Look inside $PORTDIR/sys-apps/portage/files/README.RESCUE and you'll see
> this:
>
> Please see
> http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml for a
> recovery guide for a broken portage installation.
>

yeah, but that does not change the fact, that some time (years?) ago, there 
was a portage-rescue package.

Which I even used once ... unpack it and you had a working portage - if you 
did not have destroyed python ....

;)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sat, 08 Jul 2006 02:00:27 +0300, Daniel Iliev wrote:

> 1) I would like to see an implementation of "PAUSE". I mean, during most
> of the emerges there is not only one package to be emerged. Some of the
> packages have instructions for additional post installation steps that
> the user
> should take. Well, I think there should be a "FETURE", a flag to
> "emerge" or
> some other mechanism to tell portage to wait for confirmation if the
> ebuild gives such information.

emerge is, by definition, a non-interactive program (apart from --ask
which works before emerge starts its business). Use the ELOG features of
portage 2.1 to have this messages save to a file, mailed to you or read
out with festival.

> 3) I hate ebuilds that are rewriting variables that I have set. For
> example I
> couldn't find a way to compile mplayer with
> "--disable-runtime-cpudetection",

EXTRA_ECONF="--disable-runtime-cpudetection" emerge --options mplayer

This doesn't work with every ebuild, but it does with most of them.

> many packages overwrite C(XX)FLAGS. They change "-O3" to "-O2" etc.
> "Gentoo is about choices" but why this happens? My opinion is that
> portage should warn about the "too aggressive setting" but to let ME
> chose to change the settings or not.

If it is know that the package will fail with -O3, what is the point of
letting it through, even if it warns you. However, an einfo message
whenever CFLAGS are overridden would be nice.
 

-- 
Neil Bothwick

I can see clearly now, the brain is gone...

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

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sat, 8 Jul 2006 10:00:19 +0200, Hemmann, Volker Armin wrote:

> yeah, but that does not change the fact, that some time (years?) ago,
> there was a portage-rescue package.
> 
> Which I even used once ... unpack it and you had a working portage - if
> you did not have destroyed python ....

FEATURES="buildpkg" emerge --oneshot portage python

Now you have packages for both portage and python that you can unpack
into / to repair and damage. It might be a good idea to do the same for
glibc, gcc and bash.

I have buildpkg set by default, but if space is limited, it would be
useful to be able to specify this on a per-package basis (I know this can
be done with /etc/portage/bashrc) or even be able to tell portage to only
save packages for system ebuilds.


-- 
Neil Bothwick

If nothing sticks to Teflon, how do they stick teflon on the pan?

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

Re: [gentoo-user] Things that can be improved

[Rafael Fernández López]

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

Hi guys,

	There are some things that I forgot to tell ya.

	I know that lots of you don't know "dpkg-reconfigure", well, it will
write the /etc/whatever.conf file for you asking you in an interactive
way what do you want to do. I'd compare it to some package's "ebuild
/usr/portage/whatever/whatever-0.0.1.ebuild conf".

	I would add a mark for packages that can be configured, as there is a
mark for UPDATE, NEW, RE-EMERGE, FETCH... I'd add another one like "C"
for ebuilds that admit "conf" option.

	As someone said here before, EMERGE is a not interactive tool (if we
don't take in count --ask), but in general it is not interactive. And we
can assume that anybody stays in front of monitor all the emerge
process, so I'd suggest to print information (or warning) messages in a
more efficient way, for example: AT THE END OF THE EMERGE PROCESS, not
at the end of each package emerge process. I think that
PORTAGE_ELOG_CLASSES, PORTAGE_ELOG_SYSTEM and PORTAGE_ELOG_MAILURI is
not so necessary if all messages are printed out at the end of the
global emerge process.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEr6UAWFfYaTyFH8oRAisJAJ9rzuxt/wKJPAvXoCdU9d4JcCoIkACghuPf
xEju9eUjrUPsOG7HMnM7F9A=
=cqyw
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Daniel Iliev]

Justin R Findlay wrote:
> <ctrl>-s, <ctrl>-q seems to work for me.

This means one still has to monitor the output.

> In my /etc/make.conf I have:
> 
> PORTAGE_ELOG_CLASSES="info warn error log"
> PORTAGE_ELOG_SYSTEM="mail syslog"
> PORTAGE_ELOG_MAILURI="root@jfindlay.us"

Thank you for pointing this out. It is a new stuff for me. I'll
investigate the documentation and give it a try.

--snip

>  If you tell it to, portage will log every last
> configure and gcc statement spewed forth on the command line into
> /var/log/portage/.

Yes, I already have about 400MB of logs there. I still wonder when will
come the day I'll wipe them out. :)

> Gentoo generally overwrites C(XX)FLAGS only when they are problematic
> (unpredictable or cause breakage) for certain platforms/packages.  If
> you have a customized ebuild you can always drop it into your own
> overlay.  Mine is in /usr/local/portage.  If you have multiple overlays
> you can use gensync from the gentoolkit-dev package to sync with them.
> 


The truth is there are only a few ebuilds I want to change something in.
Up to now in case I want to change something or the packages doesn't
compile the normal way, my practice is to use "ebuild `equery w
package-name` unpack", do my things in the temp dir, compile manually,
put a file ".compiled" and resume the installation.
May be I'll start using my own overlay after I collect "enough" packages.


-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Daniel Iliev]

Neil Bothwick wrote:
> On Sat, 08 Jul 2006 02:00:27 +0300, Daniel Iliev wrote:

> emerge is, by definition, a non-interactive program (apart from --ask
> which works before emerge starts its business). Use the ELOG features of
> portage 2.1 to have this messages save to a file, mailed to you or read
> out with festival.

As I already replied to Mr Justin R Findlay's email "ELOG" is something
new to me. I have to check it out. Thank you for pointing this out.

> 
> EXTRA_ECONF="--disable-runtime-cpudetection" emerge --options mplayer
> 
> This doesn't work with every ebuild, but it does with most of them.
> 

Correct. This doesn't work for mplayer.


> If it is know that the package will fail with -O3, what is the point of
> letting it through, even if it warns you. However, an einfo message
> whenever CFLAGS are overridden would be nice.
>  

Well, I can't imagine that gentoo maintainers have the opportunity to
check all the possible combinations of flags and system setting before
they release an ebuild. It is of course better that they prefer to use
the "safe way".
I thing an einfo message is the least thing they could give us, though I
prefer to have the choice to try the aggressive setting and if they
don't work for me to revert to the recommended flags.


-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Daniel Iliev]

Rafael Fernández López wrote:
> Hi guys,
> 
> 	There are some things that I forgot to tell ya.
> 
> 	I know that lots of you don't know "dpkg-reconfigure", well, it will
> write the /etc/whatever.conf file for you asking you in an interactive
> way what do you want to do. I'd compare it to some package's "ebuild
> /usr/portage/whatever/whatever-0.0.1.ebuild conf".
> 
> 	I would add a mark for packages that can be configured, as there is a
> mark for UPDATE, NEW, RE-EMERGE, FETCH... I'd add another one like "C"
> for ebuilds that admit "conf" option.
> 
> 	As someone said here before, EMERGE is a not interactive tool (if we
> don't take in count --ask), but in general it is not interactive. And we
> can assume that anybody stays in front of monitor all the emerge
> process, so I'd suggest to print information (or warning) messages in a
> more efficient way, for example: AT THE END OF THE EMERGE PROCESS, not
> at the end of each package emerge process. I think that
> PORTAGE_ELOG_CLASSES, PORTAGE_ELOG_SYSTEM and PORTAGE_ELOG_MAILURI is
> not so necessary if all messages are printed out at the end of the
> global emerge process.

I haven't investigated yet this "ELOG" thing but I couldn't I agree more
than this with you!

*CHEERS*

-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Justin R Findlay]

On Sat, Jul 08, 2006 at 05:42:25PM +0300, Daniel Iliev wrote:
> 
> Yes, I already have about 400MB of logs there. I still wonder when will
> come the day I'll wipe them out. :)

I have a simple cron job that bzip2's them and about a year's worth of
logs amounts to about 30 Mib, but I should probably rework it to expire
old logs.

> The truth is there are only a few ebuilds I want to change something in.
> Up to now in case I want to change something or the packages doesn't
> compile the normal way, my practice is to use "ebuild `equery w
> package-name` unpack", do my things in the temp dir, compile manually,
> put a file ".compiled" and resume the installation.
> May be I'll start using my own overlay after I collect "enough" packages.

I suggest putting your modifications into your own ebuild in an overlay
because it may be simpler and neater to apply your changes to the new
version/ebuild of the package when it comes out rather than having to
remember everything you did the first time manually.


Justin
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Rafael Fernández López schrieb:

> 	The first thing that I'd change is "etc-update" or "dispatch-conf". I'd
> suggest to create some kind of tool like "dpkg-reconfigure" in Debian.
> More intuitive than reading /etc files and writing them by hand that is
> more probably to be mistaken when writing.

Please do *NOT* do that! I don't want some kind of "wizard" offering
me choices, of which none might fit my needs.

Alexander Skwar
-- 
Im Endeffekt war alles cooler als letztes Jahr, obwohl
ich bis Donnerstag dachte, das es nicht geht.
		-- Igor Gilitschenski
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Rafael Fernández López schrieb:

> 	Second thing that I'd improve is a security one. I know that "emerge"
> is a very cared package, but it is a script. Suppose that someone
> commits portage with a emerge failure in its code (he forgot a comma
> !!)... if someone updates portage won't be able to update it again
> because it will fail ever and ever again... So I suggest to have a
> backuped emerge script that we are sure that worked (like the last
> emerge tool that was used), and if the new emerge tool is mistaken (so
> that user doesn't need to know python) only has to run "regenemerge" for
> example, and will have the latest emerge working tool.

I disagree with that as well. Changes should only happen in the keyworded
packages (ie. ~x86, ...). That's the testing area of Gentoo. If a package
breaks in testing: "Fine"! That's what's testing is for.

Alexander Skwar
-- 
Im Endeffekt war alles cooler als letztes Jahr, obwohl
ich bis Donnerstag dachte, das es nicht geht.
		-- Igor Gilitschenski
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Lord Sauron schrieb:
> On 7/7/06, Zac Medico <zmedico@gentoo.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Lord Sauron wrote:
>> > My personal gripe is how slow emerge is on just plain old emerge-ish
>> > things.  That we have to use things like eix to search is pathetic.
>> > This NEVER happened in Debian.
>>
>> emerge/portage has lots of room for improvement.  Lots of the code is quite messy and it has been largely neglected because most people simply refuse to do much work on such a mess.  However, since I've joined the project, I've been doing doing lots of work to clean up this code that most people won't touch.  It's getting better, slowly but surely.
> 
> Yes, it does.  However, portage aside, it lacks something like
> aptitude to really fill in the loose ends.
> 
>> There are so many technical issues that remain to be solved in portage that it's difficult to justify spending time on problems that have already been solved in one way or another.  There many tools in existence that already do the search part pretty well.  Lots of other things still need fixing...
> 
> Yeah.  Portage works, however, I think it's really in need of a large
> overhaul.  If what you're saying is true, and it's really just a load
> of scripts, then I really would HIGHLY suggest that you consider
> beginning to make smaller helper applications in C and stuff to speed
> things up.

What makes you think, that emerge in C would be faster? Would
it really be noticeably faster?

> Scripts are great, but they aren't for whole applications.

I disagree. Scripts ("interpreted computing languages" would be
more to the point, though) are great, EVEN for whole applications.
Reason: Easier and faster development.


Alexander Skwar
-- 
Im Endeffekt war alles cooler als letztes Jahr, obwohl
ich bis Donnerstag dachte, das es nicht geht.
		-- Igor Gilitschenski
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Rafael Fernández López schrieb:

> 	I know that lots of you don't know "dpkg-reconfigure", well, it will
> write the /etc/whatever.conf file for you asking you in an interactive
> way what do you want to do.

But etc-update is interactive as well, isn't it?

> process, so I'd suggest to print information (or warning) messages in a
> more efficient way, for example: AT THE END OF THE EMERGE PROCESS, not
> at the end of each package emerge process. I think that
> PORTAGE_ELOG_CLASSES, PORTAGE_ELOG_SYSTEM and PORTAGE_ELOG_MAILURI is
> not so necessary if all messages are printed out at the end of the
> global emerge process.

I used to think the same, but changed my mind with the introduction
of PORTAGE_ELOG_SYSTEM="mail" (or actually, ="custom"). Reason: This
way, I get all the messages mailed to me, for me to review. That's
*IMO* even better. Reason: You get the messages earlier and suppose
the system crashes in the middle of the emerge. If all the messages
were just shown at the end, some messages might be lost.

No. With the advent of PORTAGE_ELOG_*, everything is fine as far as
I'm concerned.

Alexander Skwar
-- 
Im Endeffekt war alles cooler als letztes Jahr, obwohl
ich bis Donnerstag dachte, das es nicht geht.
		-- Igor Gilitschenski
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sat, 08 Jul 2006 20:30:06 +0200, Alexander Skwar wrote:

> > 	I know that lots of you don't know "dpkg-reconfigure", well,
> > it will write the /etc/whatever.conf file for you asking you in an
> > interactive way what do you want to do.
> 
> But etc-update is interactive as well, isn't it?

And you can configure etc-update and dispatch-conf to use whatever you
want to applky changes to files, such as vimdiff, kdiff3 or meld.


-- 
Neil Bothwick

If you consult enough experts, you can confirm any opinion.

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

Re: [gentoo-user] Things that can be improved

[Hemmann, Volker Armin]

On Saturday 08 July 2006 11:31, Neil Bothwick wrote:
> On Sat, 8 Jul 2006 10:00:19 +0200, Hemmann, Volker Armin wrote:
> > yeah, but that does not change the fact, that some time (years?) ago,
> > there was a portage-rescue package.
> >
> > Which I even used once ... unpack it and you had a working portage - if
> > you did not have destroyed python ....
>
> FEATURES="buildpkg" emerge --oneshot portage python
>

I know that. I prefer quickpkg. ;) 

Before a big, scary update, I quickpkg gcc, glibc or what else gets updated.

Still. portage-rescue was a usefull thing.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Walter Dnes]

On Fri, Jul 07, 2006 at 09:22:29PM +0200, Rafael Fern??ndez L??pez wrote

>   This is not flame war. I love Gentoo, and it is the distribution
> that fits me perfectly, but I've been wondering this last year what
> things can be improved in this wonderful distro.
> 
>   The first thing that I'd change is "etc-update" or "dispatch-conf".

  etc-update needs only one change to make it perfect for me, namely the
ability to protect changes to default parameters.  Here are 3 examples
from a recent update, where an automaton has no business touching
certain lines...

/etc/conf.d/bootmisc
-WIPE_TMP="yes"
+WIPE_TMP="no"

/etc/conf.d/local.start
 # This is a good place to load any misc programs
-# on startup ( use 1>&2 to hide output)
-modprobe snd-virmidi index=1
+# on startup (use &>/dev/null to hide output)
+

/etc/conf.d/rc
@@ -74,7 +89,12 @@
 # and restore it on startup.  This is useful if you have a lot of
 # custom device nodes that udev does not handle/know about.

-RC_DEVICE_TARBALL="yes"
+RC_DEVICE_TARBALL="no"
+

  When I say "yes" I mean "yes".  When I say "no" I mean "no".  And I
don't mean "just until the next update" either.  I have reasons for my
settings; please don't act like Windows and assume that you know better
than me.  And there is no excuse whatsoever for wiping out the custom
settings in /etc/conf.d/local.start

  Would it be possible to have some comment declaration like...

#etc-update-protect-begin
WIPE_TMP="yes"
#etc-update-protect-end

...to protect a block of lines against changes, while allowing other
lines to be changed?

-- 
Walter Dnes <waltdnes@waltdnes.org> In linux /sbin/init is Job #1
My musings on technology and security at http://tech_sec.blog.ca
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Gerhard Hoogterp]

>   When I say "yes" I mean "yes".  When I say "no" I mean "no".  And I
> don't mean "just until the next update" either.  I have reasons for my
> settings; please don't act like Windows and assume that you know better
> than me.  And there is no excuse whatsoever for wiping out the custom
> settings in /etc/conf.d/local.start

As I wrote in an other mail: Stop interfering with the actual configfile and 
add the changes to a config.conf.dist file. There you don't have to ask for 
permission and a simple diff can reveal the changes whenever I want. 

During install a copy of this file could be installed already for direct use..

Something alike for the messages during an emerge. Often I see instructions on 
what to do after the emerge flashing by while doing an emerge world, I don't 
even want to know how many I miss.. Why not log those to a seperate file so 
one can actually find them back afterwards?

I know Gentoo is supposed to be for those who know how to deal with things, 
but that doesn't mean it should be more complicated of dangerous than 
needed.. 

Gerhard
-- 
Ithaka photography, http://funsite.mine.nu
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sat, 8 Jul 2006 22:32:58 +0200, Hemmann, Volker Armin wrote:

> > FEATURES="buildpkg" emerge --oneshot portage python
> >
> 
> I know that. I prefer quickpkg. ;) 

The difference is that the buildpkg approach verifies the package by
building it and then installing from it.
 
> Before a big, scary update, I quickpkg gcc, glibc or what else gets
> updated.

Using buildpkg means I never have to worry about forgetting to run
quickpkg, i can concentrate on all the other things I forget to do :)


-- 
Neil Bothwick

Those who can, do. Those who cannot, teach. Those who cannot teach, HACK!

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

Re: [gentoo-user] Things that can be improved

[Rafael Fernández López]

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

What to do when your smtp server needs authentification ?

Cheers,
Rafael Fernández López.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEsB2PWFfYaTyFH8oRAj9pAJwIQtBnh4+aKBHYgHeEo+YxoIjBMACfZHWr
zbnjGAFVS/F+JqZnR2HPc6E=
=i9LC
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Hemmann, Volker Armin]

On Saturday 08 July 2006 23:00, Neil Bothwick wrote:
> On Sat, 8 Jul 2006 22:32:58 +0200, Hemmann, Volker Armin wrote:
> > > FEATURES="buildpkg" emerge --oneshot portage python
> >
> > I know that. I prefer quickpkg. ;)
>
> The difference is that the buildpkg approach verifies the package by
> building it and then installing from it.
>
> > Before a big, scary update, I quickpkg gcc, glibc or what else gets
> > updated.
>
> Using buildpkg means I never have to worry about forgetting to run
> quickpkg, i can concentrate on all the other things I forget to do :)

yeah, but some people are a little bit harddisc-space constraint ;)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Ryan Tandy]

Daniel Iliev wrote:
> Neil Bothwick wrote:
>> EXTRA_ECONF="--disable-runtime-cpudetection" emerge --options mplayer
>>
>> This doesn't work with every ebuild, but it does with most of them.
>>
> 
> Correct. This doesn't work for mplayer.


tarpman@epsilon ~ $ equery u mplayer
[ Searching for packages matching mplayer... ]
[ Colour Code : set unset ]
[ Legend	: Left column  (U) - USE flags from make.conf ]
[		   : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for media-video/mplayer-1.0_pre8 ]
  U I
<snip>
  - - cpudetection  : Enables runtime cpudetection
<snip>

So, you want USE="-cpudetection" for mplayer.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sat, 8 Jul 2006 23:10:17 +0200, Hemmann, Volker Armin wrote:

> > Using buildpkg means I never have to worry about forgetting to run
> > quickpkg, i can concentrate on all the other things I forget to do :)
> 
> yeah, but some people are a little bit harddisc-space constraint ;)

Yeah, I know. That's why I thought it would be useful to be able to do
this on a per-package basis, or just for system packages.

-- 
Neil Bothwick

I've been fishing with Salvador Dali, he used a
dotted line and caught every other fish.

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

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sat, 8 Jul 2006 22:59:24 +0200, Gerhard Hoogterp wrote:

> Something alike for the messages during an emerge. Often I see
> instructions on what to do after the emerge flashing by while doing an
> emerge world, I don't even want to know how many I miss.. Why not log
> those to a seperate file so one can actually find them back afterwards?

Have you missed the dozens of references to ELOG already in this thread?


-- 
Neil Bothwick

SUBLIMINALsendmoneyTAGLINE

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

Re: [gentoo-user][OT]Things that can be improved

[Daniel Iliev]

Ryan Tandy wrote:

> 
> tarpman@epsilon ~ $ equery u mplayer
> [ Searching for packages matching mplayer... ]
> [ Colour Code : set unset ]
> [ Legend    : Left column  (U) - USE flags from make.conf ]
> [           : Right column (I) - USE flags packages was installed with ]
> [ Found these USE variables for media-video/mplayer-1.0_pre8 ]
>  U I
> <snip>
>  - - cpudetection  : Enables runtime cpudetection
> <snip>
> 
> So, you want USE="-cpudetection" for mplayer.

Ryan, thank you for trying to help.
I want runtime CPU detection disabled. This flag is supposed to enable
it when set.

Well, I want it disabled, so my flag is set correctly.

[ebuild   R   ] media-video/mplayer-1.0_pre8  USE="... -cpudetection
..." 8,882 kB

For the matter of fact after your mail I turned the flag on and off and
tried again and again. The result of ./configure phase was always the same:

Quote:
======
Config files successfully generated by ./configure !

  Install prefix: /usr
  Data directory: /usr/share/mplayer
  Config direct.: /usr/share/mplayer


  Byte order: little-endian
  Optimizing for: Runtime CPU-Detection enabled
======

Anyway this is not so important - mplayer performs fine. I used this
only for an example but it turns that may be we are talking about a bug.

Has anyone observed the same thing? That the flag "cpudetection" does
nothing, no matter if enabled or disabled?

-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user]MPlayer: CPU Detection? (was: [OT]Things that can be improved)

[Ryan Tandy]

Daniel Iliev wrote:
> Quote:
> ======
> Config files successfully generated by ./configure !
> 
>   Install prefix: /usr
>   Data directory: /usr/share/mplayer
>   Config direct.: /usr/share/mplayer
> 
> 
>   Byte order: little-endian
>   Optimizing for: Runtime CPU-Detection enabled
> ======

Byte order: little-endian
Optimizing for: pentium4 mmx mmxext sse sse2 mtrr

[ebuild   R   ] media-video/mplayer-1.0_pre8  USE="X alsa gif gtk i8x0 
jpeg mmx mmxext opengl png sse sse2 truetype unicode vorbis win32codecs 
xv xvid -3dfx -3dnow -3dnowext -aac -aalib -arts -bidi -bindist -bl 
-cdparanoia -cpudetection -custom-cflags -debug -dga -directfb -doc -dts 
-dv -dvb -dvd -dvdread -encode -esd -fbcon -ggi -ipv6 -jack -joystick 
-libcaca -lirc -live -livecd -lzo -mad -matrox -musepack -nas -nvidia 
-openal -oss -real -rtc -samba -sdl -speex -svga -tga -theora -v4l -v4l2 
-x264 -xanim -xinerama -xmms -xvmc" 0 kB

And according to the ebuild, it works properly...

if use cpudetection || use livecd || use bindist
	myconf = "${myconf} --enable-runtime-cpudetection"
fi

I'm hoping they aren't, but are livecd or bindist in your USE?  Is your 
MPlayer ebuild coming from an overlay?  Have you synced recently?
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user]MPlayer: CPU Detection?

[Daniel Iliev]

Ryan Tandy wrote:
> And according to the ebuild, it works properly...
> 
> if use cpudetection || use livecd || use bindist
>     myconf = "${myconf} --enable-runtime-cpudetection"
> fi
> 
> I'm hoping they aren't, but are livecd or bindist in your USE?  Is your
> MPlayer ebuild coming from an overlay?  Have you synced recently?

Blaah! It is all my fault. "bindist" was on. And I can't even remember
why and when I have done this. Strange.

The good news is:
===
Config files successfully generated by ./configure !

  Install prefix: /usr
  Data directory: /usr/share/mplayer
  Config direct.: /usr/share/mplayer

  Byte order: little-endian
  Optimizing for: athlon-xp mmx mmxext 3dnow 3dnowext sse mtrr
===


Thank you very much, Ryan!

-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user]MPlayer: CPU Detection?

[Ryan Tandy]

Daniel Iliev wrote:
> Blaah! It is all my fault. "bindist" was on. And I can't even remember
> why and when I have done this. Strange.
> 

Can't think why you would either.  It's meant for when you're building 
GRP packages.  You should probably turn it off if that isn't your intention.

In any case, glad I could help. :)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user][OT]MPlayer: CPU Detection?

[Daniel Iliev]

Ryan Tandy wrote:

> Can't think why you would either.  It's meant for when you're building
> GRP packages.  You should probably turn it off if that isn't your
> intention.
> 
> In any case, glad I could help. :)

Yep. I turned it off immediately after your mail. No recall how this
flag found its way into my USE. I define it like this: USE="-* flag1
flag2...flagN" and only put flags that I need. I don't have GRP
packages, actually I used a stage1 install.
Enigma. ;-)

Anyway, thanks again.

-- 
Best regards,
Daniel

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Rafael Fernández López schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> What to do when your smtp server needs authentification ?

Curse the damned too simple ELOG interface :)

That's why I wrote, that I actually use =custom. I wrote a page on
the wiki regarding this:


Alexander Skwar
-- 
The mother of the year should be a sterilized woman with two adopted children.
		-- Paul Ehrlich
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Rafael Fernández López schrieb:

> What to do when your smtp server needs authentification ?

Well, I wrote a page on the wiki. And I wanted to post the URL, but
my fingers are too clumsy :)

http://gentoo-wiki.com/TIP_Making_portage_use_/usr/sbin/sendmail_to_send_out_ELOG_mails

In this wiki TIP, I show how portage can be configured, so that
it uses /usr/sbin/sendmail to send out mails. On my system, /usr/sbin/sendmail
is SSMTP and I configured SSMTP to use auth.

But if you're *only* after being able to auth. yourself to the
SMTP server, you don't need my tip. Portage can do this by itself.
Just have a look at the description of PORTAGE_ELOG_MAILURI in
/etc/make.conf.example.

HTH,

Alexander Skwar
-- 
My friend has a baby.  I'm writing down all the noises he makes so
later I can ask him what he meant.
		-- Steven Wright
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Walter Dnes schrieb:
> On Fri, Jul 07, 2006 at 09:22:29PM +0200, Rafael Fern??ndez L??pez wrote
> 
>>   This is not flame war. I love Gentoo, and it is the distribution
>> that fits me perfectly, but I've been wondering this last year what
>> things can be improved in this wonderful distro.
>> 
>>   The first thing that I'd change is "etc-update" or "dispatch-conf".
> 
>   etc-update needs only one change to make it perfect for me, namely the
> ability to protect changes to default parameters.  Here are 3 examples
> from a recent update, where an automaton has no business touching
> certain lines...
> 
> /etc/conf.d/bootmisc
> -WIPE_TMP="yes"
> +WIPE_TMP="no"
> 
> /etc/conf.d/local.start
>  # This is a good place to load any misc programs
> -# on startup ( use 1>&2 to hide output)
> -modprobe snd-virmidi index=1
> +# on startup (use &>/dev/null to hide output)
> +
> 
> /etc/conf.d/rc
> @@ -74,7 +89,12 @@
>  # and restore it on startup.  This is useful if you have a lot of
>  # custom device nodes that udev does not handle/know about.
> 
> -RC_DEVICE_TARBALL="yes"
> +RC_DEVICE_TARBALL="no"
> +
> 
>   When I say "yes" I mean "yes".  When I say "no" I mean "no".  And I
> don't mean "just until the next update" either.  I have reasons for my
> settings; please don't act like Windows and assume that you know better
> than me.

But actually, they do *NOT* pretend to know better! The way it is
now, is, that you're asked if you wish to accept those changes

>  And there is no excuse whatsoever for wiping out the custom
> settings in /etc/conf.d/local.start
> 
>   Would it be possible to have some comment declaration like...
> 
> #etc-update-protect-begin
> WIPE_TMP="yes"
> #etc-update-protect-end
> 
> ...to protect a block of lines against changes, while allowing other
> lines to be changed?

Hm - that might actually be a good idea. While there are certain
*parts* in a configuration file that can be updated, there are
certain parts, that shouldn't be.

BUT: How should that actually work? Suppose you had this "etc-upadte-protect-begin"
and "-end" block. How should diff see, that changes in such a block
are NOT to be considered? I mean, in the original file, there's *no*
such block (and I actually wouldn't want such a block to be in default
configuration files).

Alexander Skwar
-- 
grasshopotomaus:
	A creature that can leap to tremendous heights... once.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Gerhard Hoogterp schrieb:
>>   When I say "yes" I mean "yes".  When I say "no" I mean "no".  And I
>> don't mean "just until the next update" either.  I have reasons for my
>> settings; please don't act like Windows and assume that you know better
>> than me.  And there is no excuse whatsoever for wiping out the custom
>> settings in /etc/conf.d/local.start
> 
> As I wrote in an other mail: Stop interfering with the actual configfile and 
> add the changes to a config.conf.dist file.

Yep, you wrote that, and I answered that *I* would *NOT* like this.
I like it, that I can use a program right away - at least in a
"default" way. If you had your way, *NO* program which relied
on configuration files would be usable after installation, as
no configuration file could be found. Because of that, I would
not want to happen what you proposed.

> There you don't have to ask for 
> permission and a simple diff can reveal the changes whenever I want. 

A simple diff is all that's done right now (well, basically at least;
basically etc-update can be seen as a sort of front-end to diff).

> During install a copy of this file could be installed already for direct use..



> Something alike for the messages during an emerge. Often I see instructions on 
> what to do after the emerge flashing by while doing an emerge world, I don't 
> even want to know how many I miss.. Why not log those to a seperate file so 
> one can actually find them back afterwards?

"Why not"? Simple - because it's already done that way. You can
save all the messages which meet a certain level (ie. either log
all ewarn messages, all einfo messages or both kinds of messages).

> I know Gentoo is supposed to be for those who know how to deal with things, 
> but that doesn't mean it should be more complicated of dangerous than 
> needed.. 

ACK.

Alexander Skwar
-- 
Excess on occasion is exhilarating.  It prevents moderation from
acquiring the deadening effect of a habit.
		-- W. Somerset Maugham
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[David Dalrymple]

> > There you don't have to ask for
> > permission and a simple diff can reveal the changes whenever I want.
>
> A simple diff is all that's done right now (well, basically at least;
> basically etc-update can be seen as a sort of front-end to diff).

To throw my two cents in here, I'd like etc-update to use vimdiff,
which is another front-end to diff, and much more intuitive to me.
However, doing so would probably enrage emacs users, who, presumably,
have a front-end to diff from emacs as well; so maybe an option for
vimdiff or emacs-diff -- I bet either would be better than the current
script.

--David
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Jeremy Olexa]

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

David Dalrymple wrote:
>> > There you don't have to ask for
>> > permission and a simple diff can reveal the changes whenever I want.
>>
>> A simple diff is all that's done right now (well, basically at least;
>> basically etc-update can be seen as a sort of front-end to diff).
> 
> To throw my two cents in here, I'd like etc-update to use vimdiff,
> which is another front-end to diff, and much more intuitive to me.
> However, doing so would probably enrage emacs users, who, presumably,
> have a front-end to diff from emacs as well; so maybe an option for
> vimdiff or emacs-diff -- I bet either would be better than the current
> script.
> 
> --David

David,
- From /etc/etc-update.conf:

<snip>
# vim-users: you CAN use vimdiff for diff_command. (see NOTE_1)
#diff_command="vim -d %file1 %file2"
#using_editor=1

diff_command="colordiff -uN %file1 %file2"
using_editor=0


# vim-users: don't use vimdiff for merging (see NOTE_1)
merge_command="sdiff -s -o %merged %orig %new"
</snip>

You can see here that you *CAN* use vimdiff, I personally use colordiff
which you can see above. HTH

- --
Jeremy Olexa
(olexa@cs.umn.edu)
Office: EE/CS 1-201
CS/IT Systems Staff
University of Minnesota

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEsSjIFN7pD9kMi/URAmn2AJoCs07KzgLkqiTbb/zmnT1i5iPNFgCfYW9a
JZLAHyEhGsvVkeBdss8wK5Q=
=/qHY
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

David Dalrymple schrieb:
>> > There you don't have to ask for
>> > permission and a simple diff can reveal the changes whenever I want.
>>
>> A simple diff is all that's done right now (well, basically at least;
>> basically etc-update can be seen as a sort of front-end to diff).
> 
> To throw my two cents in here, I'd like etc-update to use vimdiff,

Then configure etc-update to use vimdiff. See /etc/etc-update.conf

> which is another front-end to diff, and much more intuitive to me.
> However, doing so would probably enrage emacs users, who, presumably,
> have a front-end to diff from emacs as well; so maybe an option for
> vimdiff or emacs-diff -- I bet either would be better than the current
> script.

No, it would NOT be *BETTER*. One of the nice things of the current
default setup is, that it is rather basic.

Alexander Skwar
-- 
All international orders must be accompanied by payment in U. S. funds.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Etaoin Shrdlu]

On Sunday 9 July 2006 17:53, David Dalrymple wrote:

> To throw my two cents in here, I'd like etc-update to use vimdiff,
> which is another front-end to diff, and much more intuitive to me.

I think that vimdiff is the same as vim -d; if this is correct, just 
edit /etc/etc-update.conf and  enable vim -d for your diff_command (it's 
commented out by default).
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sun, 09 Jul 2006 17:18:32 +0200, Alexander Skwar wrote:

> > What to do when your smtp server needs authentification ?
> 
> Curse the damned too simple ELOG interface :)
> 
> That's why I wrote, that I actually use =custom. I wrote a page on
> the wiki regarding this:

What's wrong with the procedure outlined in /etc/make.conf.example (I
haven't tried it)?

# PORTAGE_ELOG_MAILURI: this variable holds all important settings for the mail
#                       module. In most cases listing the recipient address and
#                       the receiving mailserver should be sufficient, but you can
#                       also use advanced settings like authentication or TLS. The
#                       full syntax is:
#                           address [[user:passwd@]mailserver[:port]]
#                       where
#                           address:    recipient address
#                           user:       username for smtp auth (defaults to none)
#                           passwd:     password for smtp auth (defaults to none)
#                           mailserver: smtp server that should be used to deliver the mail


-- 
Neil Bothwick


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

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Neil Bothwick schrieb:
> On Sun, 09 Jul 2006 17:18:32 +0200, Alexander Skwar wrote:
> 
>> > What to do when your smtp server needs authentification ?
>> 
>> Curse the damned too simple ELOG interface :)
>> 
>> That's why I wrote, that I actually use =custom. I wrote a page on
>> the wiki regarding this:
> 
> What's wrong with the procedure outlined in /etc/make.conf.example (I
> haven't tried it)?

Regarding what OP the wants?

Nothing. When I wrote the message to which you replied, I hadn't
thought about what the OP wanted. My fault. But in my 2nd message,
I also suggested to use PORTAGE_ELOG_MAILURI, just like you now
did.

But there are potential problems which are due to the syntax of
the mailuri.

What do you do, when the username or password contains an : or @?
Especially an @ in the username might not be so strange, as it
might happen, that the username is the mailadress, incl. the domain;
something like foo@example.invalid.

Would

PORTAGE_ELOG_MAILURI="bar@example.invalid user:name@bsp.invalid:pass_with_:_colon@domain@mailserver:port"

work? For clarification:

	user=user:name@bsp.invalid
	pass=pass_with_:_colon@domain
	mailserver=mailserver
	port=port

Alexander Skwar
-- 
politics, n.:
	A strife of interests masquerading as a contest of principles.
	The conduct of public affairs for private advantage.
		-- Ambrose Bierce
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Gerhard Hoogterp]

On Sunday 09 July 2006 17:29, Alexander Skwar wrote:

> > As I wrote in an other mail: Stop interfering with the actual configfile
> > and add the changes to a config.conf.dist file.
>
> Yep, you wrote that, and I answered that *I* would *NOT* like this.
> I like it, that I can use a program right away - at least in a
> "default" way. If you had your way, *NO* program which relied
> on configuration files would be usable after installation, as
> no configuration file could be found. Because of that, I would
> not want to happen what you proposed.

Sure, and it's such a big deal to copy the dist to a non dist on first emerge 
and update the dist version afterwards. 
My whole point is that etc-update and friends should stay out of my manually 
adjusted config files once I've touched them as basicly the only thing 
etc-update is doing now is proposing to return all the settings to the 
defaults. Even if there is an new setting or something removed it would get 
lost in all the other fluff.

As for software running on pure and unchecked default configs.. That's, 
especially for more low level software, not the smartest thing to rely on. 

Gerhard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Gerhard Hoogterp schrieb:
> On Sunday 09 July 2006 17:29, Alexander Skwar wrote:
> 
>> > As I wrote in an other mail: Stop interfering with the actual configfile
>> > and add the changes to a config.conf.dist file.
>>
>> Yep, you wrote that, and I answered that *I* would *NOT* like this.
>> I like it, that I can use a program right away - at least in a
>> "default" way. If you had your way, *NO* program which relied
>> on configuration files would be usable after installation, as
>> no configuration file could be found. Because of that, I would
>> not want to happen what you proposed.
> 
> Sure, and it's such a big deal to copy the dist to a non dist on first emerge 
> and update the dist version afterwards. 

Sure, it's no big deal to make the distribution harder to use. You're
right. But you might have a hard time convincing e.g. the gentopia people
to do what you propose.

> My whole point is that etc-update and friends should stay out of my manually 
> adjusted config files once I've touched them

Then you've got no point, since etc-update and friends *do* stay out of your
files; etc-update even stays out of the configuration files, if *you*
haven't modfied them.

> As for software running on pure and unchecked default configs.. That's, 
> especially for more low level software,

Actually, it's not. Not necessarily, at least.

> not the smartest thing to rely on. 

Yes, I also think, that you're quite a stupid person. You know, I dislike
being called "not smart". And I actually find this somewhat of an offense.

Alexander Skwar
-- 
We don't need no education, we don't need no thought control.
		-- Pink Floyd
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Sun, 09 Jul 2006 20:18:25 +0200, Alexander Skwar wrote:

> Would
> 
> PORTAGE_ELOG_MAILURI="bar@example.invalid
> user:name@bsp.invalid:pass_with_:_colon@domain@mailserver:port"
> 
> work? For clarification:
> 
> 	user=user:name@bsp.invalid
> 	pass=pass_with_:_colon@domain
> 	mailserver=mailserver
> 	port=port

I've no idea, and I hope I never need to find out!

While ISP logins often use the full email address, the mailserver login
is generally just the username. If not, it looks like you're out of luck
as portage_mail.py uses the first @ to separate the authentication data
from the server. I guess it needs someone with such an address to file a
bug report.


-- 
Neil Bothwick

Life Support System Failure - Reboot Patient (Y/n)?

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

Re: [gentoo-user] Things that can be improved

[kashani]

Rafael Fernández López wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> What to do when your smtp server needs authentification ?

add sasl support to yout MTA?

kashani
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[David Dalrymple]

> You can see here that you *CAN* use vimdiff, I personally use colordiff
> which you can see above. HTH

Ah, very nice.  So then the alleged "problems" in etc-update lie not
with the frontend to diff itself, but with the idea of using a
frontend to diff (as opposed to a more complex system)?

--David
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Dale]

Richard Fish wrote:
> On 7/7/06, Daniel Iliev <danny@ilievnet.com> wrote:
>> Well, correct me if I'm wrong but it think it's not quite true.
>>
>> I *think* if you have buildpkg in your FEATURES, you will
>> get binary packages in your $PKGDIR with the new, updated versions.
>
> But previous versions are not deleted until you do an "eclean
> packages".  So yeah, you need to have buildpkg in FEATURES for a while
> to get a nice set of backup packages, or use quickpkg.
>
> -Richard

And if you have not cleaned out your distfiles, you can always just
specify the version you want to emerge as well.

Dale
:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Walter Dnes]

On Sun, Jul 09, 2006 at 05:29:06PM +0200, Alexander Skwar wrote
> Gerhard Hoogterp schrieb:
> >>  When I say "yes" I mean "yes".  When I say "no" I mean "no".  And I
> >>don't mean "just until the next update" either.  I have reasons for my
> >>settings; please don't act like Windows and assume that you know better
> >>than me.  And there is no excuse whatsoever for wiping out the custom
> >>settings in /etc/conf.d/local.start
> >
> >As I wrote in an other mail: Stop interfering with the actual configfile 
> >and add the changes to a config.conf.dist file.
> 
> Yep, you wrote that, and I answered that *I* would *NOT* like this.
> I like it, that I can use a program right away - at least in a
> "default" way. If you had your way, *NO* program which relied on
> configuration files would be usable after installation, as no
> configuration file could be found. Because of that, I would not want
> to happen what you proposed.

  I think there's a mis-understanding here.  Gerhard and I are
complaining about config files being possibly *OVERWRITTEN* with default
settings.  If there's no config file, sure write the default config
file.  But if someone has customized a config file, assume that they
know what they're doing, and leave settings alone.

-- 
Walter Dnes <waltdnes@waltdnes.org> In linux /sbin/init is Job #1
My musings on technology and security at http://tech_sec.blog.ca
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Walter Dnes wrote:

>   I think there's a mis-understanding here.  Gerhard and I are
> complaining about config files being possibly *OVERWRITTEN* with default
> settings.  If there's no config file, sure write the default config
> file.  But if someone has customized a config file, assume that they
> know what they're doing, and leave settings alone.

And that's what's currently happening - the settings are left
alone, *UNLESS* you make etc-update overwrite your original
file. But generally, the files are *NOT* touched.

Alexander Skwar
-- 
My father taught me three things:
	(1) Never mix whiskey with anything but water.
	(2) Never try to draw to an inside straight.
	(3) Never discuss business with anyone who refuses to give his name.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Dale]

Alexander Skwar wrote:
> Walter Dnes wrote:
>
>   
>>   I think there's a mis-understanding here.  Gerhard and I are
>> complaining about config files being possibly *OVERWRITTEN* with default
>> settings.  If there's no config file, sure write the default config
>> file.  But if someone has customized a config file, assume that they
>> know what they're doing, and leave settings alone.
>>     
>
> And that's what's currently happening - the settings are left
> alone, *UNLESS* you make etc-update overwrite your original
> file. But generally, the files are *NOT* touched.
>
> Alexander Skwar
>   

Correct.  I can remember when it used to try to overwrite fstab every
time, well, it seemed like it anyway.  It doesn't do that anymore
though.  It puts the new file there but the one we, the person in the
chair, changed does not get touched until you run etc-update and tell it
to change it.  Careful with that -5 option.

Sounds like some are not using etc-update correctly.

Dale
:-)  :-)


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Ryan Tandy]

Dale wrote:
> Careful with that -5 option.

delta ~ # ( while true ; do echo -5\n ; done ) | etc-update

*shifty eyes*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Daniel da Veiga]

On 7/11/06, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sun, Jul 09, 2006 at 05:29:06PM +0200, Alexander Skwar wrote
> > Gerhard Hoogterp schrieb:
> > >>  When I say "yes" I mean "yes".  When I say "no" I mean "no".  And I
> > >>don't mean "just until the next update" either.  I have reasons for my
> > >>settings; please don't act like Windows and assume that you know better
> > >>than me.  And there is no excuse whatsoever for wiping out the custom
> > >>settings in /etc/conf.d/local.start
> > >
> > >As I wrote in an other mail: Stop interfering with the actual configfile
> > >and add the changes to a config.conf.dist file.
> >
> > Yep, you wrote that, and I answered that *I* would *NOT* like this.
> > I like it, that I can use a program right away - at least in a
> > "default" way. If you had your way, *NO* program which relied on
> > configuration files would be usable after installation, as no
> > configuration file could be found. Because of that, I would not want
> > to happen what you proposed.
>
>   I think there's a mis-understanding here.  Gerhard and I are
> complaining about config files being possibly *OVERWRITTEN* with default
> settings.  If there's no config file, sure write the default config
> file.  But if someone has customized a config file, assume that they
> know what they're doing, and leave settings alone.
>

That only happens if YOU do it. No config file is EVER changed without
your permission by portage, if it does not exist, a default is copied,
but if there's already one, no.

Another thing, some programs will NOT WORK AT ALL if you do not update
your config files, been there, done that. If your program, in its
evolution process, increases security, changes some variable names,
change its behavior in any way while dealing with config files, and
you keep your old config, you're in trouble. Gentoo gives you the new
format config file, so you can merge changes interactively, avoiding
problems and keeping your config up-to-date. What other config file
protection does that?!

> --
> Walter Dnes <waltdnes@waltdnes.org> In linux /sbin/init is Job #1
> My musings on technology and security at http://tech_sec.blog.ca
> --
> gentoo-user@gentoo.org mailing list
>
>


-- 
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
------END GEEK CODE BLOCK------
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Devon Miller]

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

On 7/9/06, Alexander Skwar <listen@alexander.skwar.name> wrote:
>
> Would
>
> PORTAGE_ELOG_MAILURI="bar@example.invalid user:name@bsp.invalid:
> pass_with_:_colon@domain@mailserver:port"
>
> work? For clarification:
>
>         user= user:name@bsp.invalid
>         pass=pass_with_:_colon@domain
>         mailserver=mailserver
>         port=port


Well, ymmv, but assuming the mailer parses the uri the same way HTTP does,
You would have to percent encode the character with special meanings: So, it
would be more like this:

        user=user%3Aname%40bsp.invalid
        pass=pass_with_%3A_colon%40domain
        mailserver=mailserver
        port=port

Yeilding:

        PORTAGE_ELOG_MAILURI=\
            "bar@example.invalid
user%3Aname%40bsp.invalid:pass_with_%3A_colon%40domain@mailserver:port"

(Line break added to discourage wrapping)

dcm

[-- Attachment #2: Type: text/html, Size: 2030 bytes --]

Re: [gentoo-user] Things that can be improved

[Gerhard Hoogterp]

> >   I think there's a mis-understanding here.  Gerhard and I are
> > complaining about config files being possibly *OVERWRITTEN* with default
> > settings.  If there's no config file, sure write the default config
> > file.  But if someone has customized a config file, assume that they
> > know what they're doing, and leave settings alone.
>
> That only happens if YOU do it. No config file is EVER changed without
> your permission by portage, if it does not exist, a default is copied,
> but if there's already one, no.

Sure and if Ihad lots of time I would do an emerge world every day just to 
check a few files. Regretfully, with 5 servers, some 28 websites and some 
other work too I don't have that daily time. So when I update my system I 
have to go through pages full of diffs, checking every diff to see if, 
besides all the settings returning to default, there are also changes that I 
should be aware off. A wrong key is easily pressed and there you go.. 

And why? Yes I changed my settings and yes etc-update or dispatch-conf show me 
carefully every moved point or comma. Thanks, but I know I changed those and 
I did that on purpose. Untouched files are already on auto-pilot. 
Show me what is added or removed. And since it can only do that by comparing 
the new file to a clean, untouched, original file I innocently suggested to 
have such a file, make changes there and leave it up to the admin to check if 
settings are added or removed and deal with these changes in the active 
config file.. And in that case don't bother showing the diff.. just tell me 
which files have changed and *offer* to show the changes. 
But don't touch my active configes.. not automatically, not ever..

Guess I'm just paranoid.. but then again, sometimes a healty amount of 
paranoia keeps you out of a lot of troubles..

Gerhard

-- 
Ithaka photography, http://ithaka.mine.nu/
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Alexander Skwar]

Gerhard Hoogterp schrieb:
>> >   I think there's a mis-understanding here.  Gerhard and I are
>> > complaining about config files being possibly *OVERWRITTEN* with default
>> > settings.  If there's no config file, sure write the default config
>> > file.  But if someone has customized a config file, assume that they
>> > know what they're doing, and leave settings alone.
>>
>> That only happens if YOU do it. No config file is EVER changed without
>> your permission by portage, if it does not exist, a default is copied,
>> but if there's already one, no.
> 
> Sure and if Ihad lots of time I would do an emerge world every day just to 
> check a few files. Regretfully, with 5 servers, some 28 websites and some 
> other work too I don't have that daily time. So when I update my system I 
> have to go through pages full of diffs, checking every diff to see if, 
> besides all the settings returning to default, there are also changes that I 
> should be aware off.

Maybe you should also be aware of changed defaults.

> A wrong key is easily pressed and there you go.. 

...to get your backup. What's the problem? You *DO* have backups,
don't you? It would be quite irresponsible to NOT have backups. But
who am I telling that.

> And why? Yes I changed my settings and yes etc-update or dispatch-conf show me 
> carefully every moved point or comma. Thanks, but I know I changed those and 
> I did that on purpose. Untouched files are already on auto-pilot. 

The "auto-pilot" *MIGHT* be bad as well. Maybe a default was changed
and the user wants to keep the old default. With an auto-pilot, that's
quite hard. But you know that, don't you?

> Show me what is added or removed.

And please also, what's *CHANGED*.

> And since it can only do that by comparing 
> the new file to a clean, untouched, original file I innocently suggested to 
> have such a file, make changes there and leave it up to the admin to check if 
> settings are added or removed and deal with these changes in the active 
> config file.. And in that case don't bother showing the diff.. just tell me 
> which files have changed and *offer* to show the changes. 

You *ARE* offered to see the changes. NOTHING's forcing you to see
the changes. When you run etc-update, you've got the option to enter
"1", "2", "42" to see those changed configuration files.

> But don't touch my active configes.. not automatically, not ever..

Okay, so you're fine with etc-update, you say?

Alexander Skwar
-- 
Yow!  Now we can become alcoholics!
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Hans-Werner Hilse]

Hi,

On Tue, 11 Jul 2006 21:07:42 +0200
Gerhard Hoogterp <gerhard@frappe.xs4all.nl> wrote:

> Show me what is added or removed. And since it can only do that by comparing 
> the new file to a clean, untouched, original file I innocently suggested to 
> have such a file, make changes there and leave it up to the admin to check if 
> settings are added or removed and deal with these changes in the active 
> config file.. And in that case don't bother showing the diff.. just tell me 
> which files have changed and *offer* to show the changes. 
> But don't touch my active configes.. not automatically, not ever..

Hm, OK, *now* I understand your point. You want to track your own, hand
made changes that don't have anything to do with new versions of
default config files except from that you want to show those changes
when making your decisions, correct? So basically, you want a
three-pane (even better, though I can't image it visually: a
tri-angular) view: Old default config, your modified version and new
default config, i.e. kind of a diff3 approach. I agree, that would be
interesting. Maybe this could easily be archieved with unionfs, having
changed files in an overlayed file system. Another option would be to
use a full fledged concurrent version system in /etc. Probably RCS
might even be sufficient.

In fact, if there are still binary packages for the old version of the
package that brought in the new config file version, it would even be
possible to extract the old default config and use that.

-hwh
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Allan Gottlieb]

[Discussion about etc-update (and friends) changing something that was
set by the user]

I believe there is a misunderstanding.  Perhaps what the OP is noting
is that etc-update gives you diffs between

  * The file as on your system (which may have user changes)

  * The file as in the current emerge of this package

I believe he would prefer to know the difference

  * The file as in the previous emerge of this package

  * The file as in the current emerge of this package

Then he would decide what to do with these changes.

I use etc-update but I believe that dispatch-conf can keep an RCS
revision history.  This should help determine the desired difference.

I apologize if it is I who have misunderstood the conversation and am
increasing the confusion.

allan
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Dale]

Allan Gottlieb wrote:
> [Discussion about etc-update (and friends) changing something that was
> set by the user]
>
> I believe there is a misunderstanding.  Perhaps what the OP is noting
> is that etc-update gives you diffs between
>
>   * The file as on your system (which may have user changes)
>
>   * The file as in the current emerge of this package
>
> I believe he would prefer to know the difference
>
>   * The file as in the previous emerge of this package
>
>   * The file as in the current emerge of this package
>
> Then he would decide what to do with these changes.
>
> I use etc-update but I believe that dispatch-conf can keep an RCS
> revision history.  This should help determine the desired difference.
>
> I apologize if it is I who have misunderstood the conversation and am
> increasing the confusion.
>
> allan
>   

Maybe I have something set different but mine does tell what is going to
be changed between the two files and you can select what you want to
change or not change.

Dale
:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Benno Schulenberg]

Allan Gottlieb wrote:
> I believe he would prefer to know the difference
>
>   * The file as in the previous emerge of this package
>
>   * The file as in the current emerge of this package
>
> Then he would decide what to do with these changes.

Precisely.  When Portage makes a ._cfg0000_* file, it should record 
this file also in /var/db/pkg/..., and upon the next emerge of that 
same package, etc-update should show the diff between that file and 
the new one.

Benno
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Allan Gottlieb]

At Tue, 11 Jul 2006 16:01:00 -0500 Dale <teendale@vista-express.com> wrote:

> Allan Gottlieb wrote:
>> [Discussion about etc-update (and friends) changing something that was
>> set by the user]
>>
>> I believe there is a misunderstanding.  Perhaps what the OP is noting
>> is that etc-update gives you diffs between
>>
>>   * The file as on your system (which may have user changes)
>>
>>   * The file as in the current emerge of this package
>>
>> I believe he would prefer to know the difference
>>
>>   * The file as in the previous emerge of this package
>>
>>   * The file as in the current emerge of this package
>>
>> Then he would decide what to do with these changes.
>>
>> I use etc-update but I believe that dispatch-conf can keep an RCS
>> revision history.  This should help determine the desired difference.
>>
>> I apologize if it is I who have misunderstood the conversation and am
>> increasing the confusion.
>>
>> allan
>>   
>
> Maybe I have something set different but mine does tell what is going to
> be changed between the two files and you can select what you want to
> change or not change.

I don't think it is a settings difference.  I believe it is giving you
the differences between the first two files I listed above and the OP
wanted the difference between the last two

allan
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[David Corbin]

On Friday 07 July 2006 15:22, Rafael Fernández López wrote:
> Hi,
>
> 	This is not flame war. I love Gentoo, and it is the distribution that
> fits me perfectly, but I've been wondering this last year what things
> can be improved in this wonderful distro.
>
<snip>
> 	If I have more ideas I'll tell ya.

I've got one. MOST packages you can emerge an update, 'merge' your config 
files using etc-update or something, and everything is happy.

But there are many packages that require more to be done.  Some of these are 
more involved (like the X11 7.0 upgrade).  Other just require (or strongly 
suggest) another special tool be run (gcc-config, fix_libtool_files.sh, and I 
seem to recall others) too.

Most of these that require more tend to be 'key' to safe/proper maintenance of 
the system.  

I'd like to see an option where certain packages are not upgrade just because 
they're out of date, but require an additional command line argument.  
Additionally, a tool that I could run that tells me "the following packages 
are being 'held back' because a more involved upgrade" - ideally, it would 
also provide information on what the required steps are.

I'm I crazy?

David

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Richard Fish]

On 7/11/06, David Corbin <gentoo.org@machturtle.com> wrote:
> I'd like to see an option where certain packages are not upgrade just because
> they're out of date, but require an additional command line argument.
> Additionally, a tool that I could run that tells me "the following packages
> are being 'held back' because a more involved upgrade" - ideally, it would
> also provide information on what the required steps are.
>
> I'm I crazy?

I don't think so.  Your comments are very much in line with
mine...trying to make the more involved upgrades less error prone.

The one concern I have with taking this out of the standard update
process is that we really need to keep up with the currently 'stable'
software as a minimum.  Updating some things that are "simple", but
letting other packages fall behind, is just asking for breakage at
some point.  Some recent postings to -dev regarding current software
not building with old gcc versions really point out this fact...

So I don't think we need yet another tool here.  I would prefer to see
our existing tools enhanced with this goal in mind.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Enrico Weigelt]

* Rafael Fernández López <info@maestroprogramador.com> wrote:

<snip>

> 	The first thing that I'd change is "etc-update" or "dispatch-conf". I'd

thanks for the tip to "dispatch-conf". Again learned something new :)
This is what I was just looking for.

BTW: if you change some config file by hand, it's seems wise to add
some comment, so you always get a hint in the diff.

BTW#2: is there any option to diff trim off ending whitespaces on 
each line before comparing ? I sometimes see changed lines where I
actually can't see any difference, so there're probably just some
ending whitespaces added/removed.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Things that can be improved

[Neil Bothwick]

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

On Thu, 27 Jul 2006 15:34:52 +0200, Enrico Weigelt wrote:

> BTW#2: is there any option to diff trim off ending whitespaces on 
> each line before comparing ? I sometimes see changed lines where I
> actually can't see any difference, so there're probably just some
> ending whitespaces added/removed.

# Automerge files comprising only whitespace and/or comments
# (yes or no)
replace-wscomments=yes

in /etc/dispatch-conf.conf


-- 
Neil Bothwick

System halted - Press all keys at once to continue.

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

[gentoo-user] Re: Things that can be improved

[Remy Blank]

Enrico Weigelt wrote:
> thanks for the tip to "dispatch-conf". Again learned something new :)
> This is what I was just looking for.

I keep my /etc as a Subversion working directory. With an additional
script, file ownership and permissions are stored in an SVN property.
That way, I can always see what has changed after an etc-update (or even
an emerge, sometimes files are moved around), and revert changes if I
screwed up. Well, all the nice features of a revision control system.

> BTW: if you change some config file by hand, it's seems wise to add
> some comment, so you always get a hint in the diff.

That would be placed in a commit message.

-- Remy


Remove underscore and suffix in reply address for a timely response.

-- 
gentoo-user@gentoo.org mailing list