[gentoo-amd64] Re: Compiler Flag -m64 Gives Warning

[Duncan]

Volker Armin Hemmann <volkerarmin@××××××××××.com> posted
200904251903.22817.volkerarmin@××××××××××.com, excerpted below, on  Sat,
25 Apr 2009 19:03:22 +0200:

> On Samstag 25 April 2009, Frank Peters wrote:
>> On Fri, 24 Apr 2009 21:14:21 +0000 (UTC)
>>
>> What I would really like to have, though, is a way to get portage to
>> recognize packages that I have installed myself.
>
> there is. You have to read the handbook. Or man 5 portage
>
>  package.provided

Indeed.  I'm sure a lot of folks have a package or two in 
package.provided.

One tip that I've come up with based on my own experience is to use 
versions in package.provided much like they do for "live" versions of 
packages.[1]  That is, for the kernel as an example, which I had always 
handled myself but which a few packages do depend on, I put 2.6.999 in 
package.provided, so nothing (for the foreseeable future) will ever 
require a newer version than is in package.provided.  Had I taken the 
suggestion VAH quoted from the manpage and used 2.6.7, various packages 
would have likely required something newer by now.

Another package I have listed in package.provided is mail-mta/ssmtp-999, 
matching a dependency of the @system set.  I run kmail and at first 
didn't have anything setup for "system" mail at all, but a few years ago 
I came up with a script that can be invoked by cron, for instance, for 
its local mail, that puts it in a local maildir folder that kmail reads.  
I had and have no need for a real smtp daemon or application, and didn't 
particularly want my local sysadmin mail going to my ISP for processing 
anyway, so a script that simply properly placed it in a local maildir 
folder for kmail to pick up was appropriate, and before that, having the 
local mail attempt fail wasn't a big deal since no one was reading it 
anyway.

But the biggest package list in package.provided here, is because I chose 
to install the xorg-x11 meta-package.  The Gentoo X project's 
recommendation is that people instead install xorg-server and the 
individual packages they need directly, rather than the meta-package, 
which lists as dependencies a lot of packages (including an unfree font 
or two) that upstream xorg likes but that most folks have no real 
practical use for on their system.  But I chose to install the meta-
package anyway, but package.provided a bunch of stuff, mostly fonts, that 
I decided I didn't need.  In addition to fonts I have x11-apps/xsm-99 and 
x11-terms/xterm-999 listed.  I use KDE and if it breaks, prefer to fix it 
at the text console, rather than have a fallback Xsession, so I don't 
need xsm, and use konsole and therefore don't need xterm.

.....

Another file to be found in /etc/portage/profile/ is the packages file, 
as an extension to the cascading set of packages files found in your 
profile and its parents.  You can of course read the portage manpage for 
the details of purpose and format, but the reason I mention it is because 
I have a single entry there:

-*sys-apps/busybox

I don't need busybox (which indeed, I had to bypass on original install 
back in 2004, as it wouldn't compile, and still wouldn't last time I 
tried, in maybe 2007, but since I don't need it, it has been easier to 
tell portage that than to figure out why it wouldn't compile, and I've 
had no reason to try since) because 1) I don't use an initramfs/initrd, 
and 2) I keep a tested bootable backup snapshot of my working system 
around on a different partition, complete with the full versions of all 
the utilities busybox provides as that's exactly what my backup is, a 
snapshot of my working system taken periodically, when it was in known 
good working order.  Thus, in the emergency situations when most folks 
would be trying to repair their system with a limited set of tools as 
found in busybox and their initramfs/initrd, I simply boot to the backup 
copy of root and have the fully functional system ready to go just as it 
was when I took the snapshot of my working system. =:^)  Thus, no need 
for busybox, and I can safely remove it from the @system set as unneeded, 
which is exactly what the above line in the packages file does.

.....

As you can see, Gentoo and portage really are very flexible, WAY more 
flexible than meets the eye on original examination, and in fact, much 
more flexible than most distributions, certainly than most binary 
distributions.

Of course, there'd be another way to do it too, if the above methods 
weren't available.  Since portage works with overlays and these can 
contain all sorts of additional ebuilds and assorted support files as 
necessary, it's always possible and in fact encouraged for those knowing 
enough bash and etc to do so, to create your own ebuilds.  Since all an 
ebuild really is, is a framework for automating the same installation 
steps one would take to install a package manually, it's relatively easy 
to create an ebuild to handle it for you.  Not only does this automate 
the steps one would ordinarily take manually, but it also lets the 
package tracking system know that you have it installed and track it as 
it normally would. =:^)

But, there's another angle to it as well.  If you really do want to 
handle it manually (or automated but using methods outside of portage), 
and even if the above package.provided, etc, weren't there, since it's 
possible to create your own ebuilds, it's possible to create what amounts 
to "null" or "noop" ebuilds. These wouldn't actually install anything; 
they'd simply tell portage it's installed.  Actually, if you look around, 
the Gentoo tree itself makes use of this type of package.  There's 
virtual packages and meta-packages.  These can depend on other packages 
and be depended on in turn, but don't actually install anything 
themselves.  The above mentioned xorg-x11 is one example.  If you're a 
KDE person, installing kde-meta installs a whole set of meta-packages 
(kdebase-meta, kdegraphics-meta...) as dependencies, but itself installs 
nothing but the name, each of which install a whole set of individual 
packages (kdebase-meta installs kcontrol, konqueror, etc).

Thus, even if package.provided didn't exist, it would be possible to 
create "empty" ebuilds in your overlay that didn't actually install the 
package but simply told portage it was installed, so it could use it for 
dependency tracking and similar purposes.

Now tell me this.  Had you any /idea/ Gentoo was that flexible?  I 
certainly hadn't the foggiest when I first started, and to this day it 
continues to amaze me just how flexible it can be!  Yet just as Linux 
itself, it's continually improving, getting even MORE flexible, allowing 
people to do even more in ever easier ways, with the same set of basic 
tools.

.....

Oh, something else to mention.  Maybe this is covered in the handbooks 
now but if so it's new.  Gentoo actually has three package managers, 
portage being only one.  Now portage remains the default PM, the one it 
is assumed people are running unless there is reason to believe 
otherwise, the one most of the Gentoo documentation covers, and the one 
recommended for newbies for all those reasons.  However, there's an 
evolving EAPI specification that all ebuilds in the official Gentoo tree 
must follow (tho there are public overlays available, some officially 
supported, some not, that use experimental EAPI versions), that has made 
it possible for other package managers to be built as well.  You will at 
some point come across reference to these, so I might as well explain the 
idea here.

pkgcore is a Gentoo package manager implementation that was intended 
originally as a portage rewrite, as portage at the time (and to some 
degree still) had a lot of old crufty "spaghetti code" that had built up 
over the years and was getting difficult to maintain.  But it evolved 
into its own project.  pkgcore is written and maintained by a former 
portage developer, and like portage, is written in python and bash.

paludis is an entirely independent Gentoo package manager written in C 
(with I believe some bash as well, as parsing bash can be really hard to 
get right with anything /but/ bash, and the ebuilds are of course bash 
based).  Because it's written in C, it's much faster in some regards (tho 
of course the actual compiles still take real time).  The development 
team is also quite happy to implement various experimental EAPIs and the 
like before they're implemented in the other two PMs, so some of the most 
experimental cutting edge overlays may require it.  There are, however, 
two drawbacks that I'm aware of.  First, unless they recently added it, 
paludis has no binpkg support at all.  As should be very obvious from my 
first reply, I like my binpkg support so that rather eliminates it as a 
possibility for me.  Second, let's just say that the lead developer, 
while an incredibly gifted coder, doesn't get along so well with some 
people, both Gentoo devs and users.  As such, while paludis is a 
supported PM, some of the humans dealing with the bugs you might file or 
the questions you might ask on the lists and forums while using said PM, 
may be doing that support somewhat less voluntarily cooperatively than 
they might be with say portage.  One hopes they remain professional, 
especially on bugzilla but also on the forums and lists.  However, it's 
an unfortunate fact that regardless of its technical merits, paludis 
users do have this history to deal with.  It's something that some may 
prefer not to deal with, in which case, sticking with the default portage 
is their best bet.  (pkgcore is somewhat in the middle.  It doesn't have 
the political negatives paludis has, but it's not the assumed default, 
either.  As they say, YMMV.)

Me?  I've stuck with portage.  It is the assumed Gentoo default which 
does make things easier at times, and I've found Zac (zmedico), the 
portage project lead, very easy to work with.  I run ~arch and sometimes 
test still masked for testing versions of various packages as well, so 
file my share of bugs as well as tracking many more others have filed, 
including some on portage.  For his consistency, cooperativeness, and 
general respect for all, users and developers alike, Zac has gained my 
utmost respect.  While I've thought about trying pkgcore, I really enjoy 
watching as portage improves and develops new features along with the 
bugs they invariably bring, then watching them get fixed.  While he's not 
perfect, Zac's handling of all that is a rare thing, something that 
simply clicks with me, and as long as he's portage lead, there's a good 
chance I'll stick with portage.

.....

[1] A few packages in the tree have "live-vcs" versions, each time you 
recompile them, they grab the git/svn/bazaar/whatever HEAD code and at 
least /try/ to compile and install it "live".  Thus, unlike most 
packages, they don't have a real "version", other than perhaps a revision 
number, but at present, portage itself doesn't track that.  For this 
reason and others, "live" packages are never unmasked so normal users 
don't see them, only those that specifically use package.unmask and 
perhaps package.keywords to allow portage to install those specific 
packages.  A convention for such packages is that the version number is 
9999 or 1.4.9999 (for live branch versions) or similar, so for those 
choosing to unmask and merge them, they always have a higher version 
number and therefore take precedence over the normal versions, which is 
what people normally want.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman