Re: [gentoo-dev] FEATURES to cut the excess in portage
Look into INSTALL_MASK. --Brian Jackson On Nov 5, 2006, at 12:02 PM, John Jawed wrote: Two patches which allow a user to bypass files created with doman and dodoc in FEATURES: FEATURES=noman nodoc emerge -av foo http://jawed.name/dev/gentoo/nodoc.patch http://jawed.name/dev/gentoo/noman.patch Quick background/inspiration: I found myself having to make an initrd suitable to do PXE boots for our business and educational clusters. I was exploiting the ever so useful ROOT option for portage to emerge packages into the initrd build directory. However, because this was an initrd being sent over the network, total size was important. At larger sizes the loading the initrd would actually cause a kernel panic on pivoting root...whether this was a result of a kernel config, a set maximum size limit, or something else I'm not exactly sure of. Looking at the output of du, I started first by removing the man and documentation files. This brought the size of my final initrd down significantly (~287MiB to ~242MiB). Possible issues/bigger picture: While I was making the changes to doman and prepman, I kept thinking of how this really is part of a bigger picture, [I think] maybe the whole minimal concept should be abstracted out of USE (for packages that have it) and be part of FEATURES (for all packages). In my case because I was using ROOT in portage to build out an initrd, I didn't really need or want man or documentation for the packages I was putting in. At the end of the day, maybe there should be a specific mix of FEATURES such as nodoc noman and/or a granular mix of minimal which encompasses the previous+more. Obviously it's open for a lot of discussion and the patches attached should/would probably not be a final solution...the goal was that this would be a start. We've been using this patch and it's worked out for us well. Your mileage may vary, if it does, please say something! :-) Thanks, John PS Sorry to the devs I was working with (you know who you are :-) for my inactivity lately...moving my life 1600 miles on a weeks' notice hasn't exactly been the easiest thing, definitely hasn't helped for the free time column. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] Developer retirement
Or better yet, get the hint that someone was making fun of you for bitching about someone else's top posting when you replied to the wrong list. --Iggy On Oct 16, 2006, at 2:28 PM, Donnie Berkholz wrote: Jakub Moc wrote: Andrej Kacian napsal(a): Fix your mail client, and don't lay the blame on infra. I never did a misplaced reply with mine. I don't see what's there to fix, already told that the behaviour is damned inconsistent with all other mailing lists. Fix the mailing list, ktnxbye, don't have time for such nonsense. Why don't you use Reply All or Reply to List, like everyone else? Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
On Oct 11, 2006, at 12:37 PM, Zac Medico wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stuart Herbert wrote:
Whatever happened to the work to implement GLEP 42? Is there anyone
actively working on this atm?
It's been on my todo list, but I haven't gotten around to it yet due
to other portage work that's kept me extremely busy. I hope to get
GLEP 42 implemented soon though.
On the bright side, portage-2.1.2 [1] has made recent progress on
quite a few important and long standing bugs. Here are descriptions
of some of the recent changes:
* Profiles support multiple inheritance.
* CONFIG_PROTECT and CONFIG_PROTECT_MASK both support files (not
just directories).
* Collision protection handles symlinks properly.
* Dependencies can be satisfied by installed packages that do not
have matching ebuilds in the portage tree or overlay.
* Emerge automatically ignores blockers that are made irrelevant by
an upgrade.
* Emerge builds a complete dependency graph in order to ensure
correct merge order and detection of circular dependencies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
I thought we were eventually going to use that format to specify deps
with specific USE set.
--Iggy
Zac
[1] http://bugs.gentoo.org/show_bug.cgi?id=147007
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLSvG/ejvha5XGaMRArOGAKDNpWrM6t6yOI2UWpzdSMNZI5aDCQCeOGGr
2WPgtPacSdHZFWPzib/H4v8=
=n+s3
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
You could handle it the way the baselayout ebuild does.
--Iggy
Stefaan wrote:
Hi!
I'm having an issue with the openafs-ebuild, and I don't see a
solution for the moment. I wondered if someone on the list would:
Prerequisite:
The ebuild needs to create the /afs directory, and remove that same
directory when it is uninstalled.
The obvious solution seems to do keepdir, so portage would attempt
to make the directory and put a .keep file in there. I say attempt,
because the following problem will occur during an re-merge or
upgrade, while the mountpoint is in use:
!!! Cannot write to '/afs'.
!!! Please check permissions and directories for broken symlinks.
etc.
(This is related to bug #9849, if I'm not mistaken)
The currently implemented solution is to do
pkg_prerm()
{
rmdir /afs 2 /dev/null
}
pkg_postinst()
{
mkdir /afs 2 /dev/null
}
which works fine when remerging an already emerged ebuild. That's
because pkg_prerm is ran first, and pkg_postinst afterwards.
However, during an upgrade, pkg_prerm of the old version is ran
_after_ pkg_postinst of the new version. This results in the
directory disappearing, and therefore afs failing to start.
Any input is greatly appreciated,
Thanks,
Stefaan
--
Stuff for sale -- http://www.brianandsara.net/temp/forsale.html
Gentoo Linux -- http://www.gentoo.org
IVTV -- http://ivtv.writeme.ch
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Say no to static libraries!
Ervin Nemeth wrote: snip I've got no full solution. The EXTRA_ECONF way works only for automake packages. Using INSTALL_MASK='*.a' makes me really, really terrified if I think about sys-devel/gcc. /Ervin Solar had a nifty per package INSTALL_MASK in his bashrc at one point I think. --Iggy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE=minimal for kernel sources
At one time we had a problem with gentoo sources having way too many use flags and patches which lead to there being an incalculable number of ways that gentoo -sources could turn out. It was a pita to maintain. A pita to troubleshoot. There were weird bugs that we couldn't reproduce easily. Basically, it was one of the worst packages to maintain in Gentoo. We had to adopt an attitude of complete loathing for kernel source packages having multiple outcomes. This loathing is probably still embedded somewhere in all of us that have been on the kernel team at one point or another. --Iggy Jan Kundrát wrote: John Mylchreest wrote: For the record, there is a bug open for this. (#64009) Personally, I'm not keen on the idea. the only way which we can do this is by detecting which arch we are installing the sources, for, which immediately means many installs of USE=minimal are not the same. Er, but why is this a problem? Does it matter that the package will install different files on x86 than on mips? Or am I just overlooking the point? -jkt -- I top post... suck it -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuild design issue regarding some {I need the lib and api only}-DEPENDs
Use INSTALL_MASK to keep /usr/bin/mysqld or whatever from getting installed. We aren't generally in the habit of splitting packages into a bunch of different ebuilds. There are exceptions, but --Iggy Christian Parpart wrote: Hi all, well, regarding the request on bug 88490 [1] (and my own needs) I'm in a deep problem ;) There *are* packages out there, that depend on (networking) client libraries (and their headers of course); for the general mysql ebuild, I'd propose the following splitup: * dev-db/mysql-server (or myssqld) * net-libs/libmysqlclient * dev-db/mysql (a meta package that simply depends on both, for backward compat) The reason is, that some packages need to talk to (SQL )servers, but some host installation do not need - or even want to (think about security policies) - a local (SQL) server; Using the minimal useflag for this - IMHO - is a misuse of the idea of minimal semantically - as I do understand minimal in a way like don't overbloat me with patches and other feature additions-alike. This idea of course is applicable for lots of more packages, but mysql is one use case where I myself ran into; Do we have a general accepted gentoo policy for this? And... any thoughts on this subject? Regards, Christian Parpart. [1] http://bugs.gentoo.org/show_bug.cgi?id=88490 -- I top post... suck it -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
Martin Schlemmer wrote: On Fri, 2005-07-01 at 15:59 -0700, Drake Wyrm wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote: Currently, we pretty much leave out the big dogs of build depends from ebuilds- basically we rely on the profile to require a suitable toolchain. Couple of issues with this though- so what you're proposing is that we add binutils/gcc/glibc to every package that compiles something Can you compile without binutils/gcc/glibc? No? Then you need it. make to every package that uses make, Again, if you depend on make, then DEPEND on make. sed/grep/bash/coreutils to every package which runs configure That's quite an interesting case. Yes, those should be in DEPEND, but it might be prudent to create an appropriate shortcut instead of explicitly adding each of those. This is all well and dandy, but try to add coreutils as a dependency of itself, or gcc of itself, or sed ... or grep ... etc, and then try to do a stage1 install (probably stage2/3 as well, but I never do those, so rather wont comment). Big picture here: * BDEPEND does nothing now, so don't worry about it if you don't want to * in the future it will make other things possible * give the man problems you see with the proposal, not just tell him that portage doesn't handle it right now... I think out of anyone, he knows what portage does and doesn't handle --Iggy The point that Mike and I make, is that portage cannot handle this (and probably wont be able to in future without a _lot_ of black magic), and this is why we need the system profile which have just the right amount of DEPEND magic to make it work, and then everything else depends automagically on the system profile (and everything in it). Making the adding of system packages to non system packages really redundant. Sure it might be fixable, but the only way I see how, is to have a complete system profile (with all the dependencies that are currently lacking), and then # emerge --oneshot --nodeps $(cat /some/path/system-profile) But this gets to the verge of being too static, having the effect that some optional dependencies for the system profile cannot be used. (There are probably other ways, but this is the first that I could think of, and more as an example ...) Thanks, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
Martin Schlemmer wrote: snip Big picture here: * BDEPEND does nothing now, so don't worry about it if you don't want to * in the future it will make other things possible * give the man problems you see with the proposal, not just tell him that portage doesn't handle it right now... I think out of anyone, he knows what portage does and doesn't handle I did ask Brian in another reply how he thought to implement it. This one however I read as Drake saying/asking that we should start doing it now, and I tried to explain why we could not up until now, and still cannot. Correct me if I interpreted it wrongly. I don't know why we can't start now if we want. BDEPEND will be silently ignored, so current versions of portage will just be blissfully ignorant. Am I missing something? Some of us think we can't start now, others think we can. I was under the impression from ferringb that we could. --Iggy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Software patents
If someone removes something that belongs to me, software patents or not, I'll be asking for removal of (at the very least) their cvs access. If not, I'll be asking for their total removal from the project. You can have all the views you want on the world. I do. This is a technical project, not your own personal soap boxes. --Iggy twofourtysix wrote: I applaud all those people on the Planet who are posting anti-software-patent banners in their blogs. It's good to see yet another major software project taking a stance. Are these people prepared to back up their views by removing from the tree all those ebuilds for software made by companies who make heavy use of software patents? That would be far more effective, and may even encourage a few mainstream tech news sources to stop ignoring the issue. I can think of quite a few software-patent friendly companies who are currently gaining significant good PR from being 'supported' by Gentoo. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting one source package into many binaries
Rafael Espndola wrote: I am using Gentoo to build some small systems. While things like the minimal useflag is a joy, the monolithic nature of most gentoo packages is a headache. Kde has been spit and libstdc++ can be installed without gcc but there are many other packages that don't have this feature. For example, installing qt also installs qt designer. Use INSTALL_MASK to keep it from getting installed. Keep both pieces. Has someone worked on changing ebuild so that it could create many binary packages from one source? Something similar to debian's dpkg-buildpackage. For example, it would be wonderful to be able to do ebuild qt-something.ebuild split-package and have in /usr/portage/packages a package for qt-designer and a package for the rest of the library. Is this a bad idea or simply not the Gentoo way? Thanks for any comments -- Rafael vila de Espndola -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keywording, for the umpteenth time
Jason Wever wrote: snip From my perspective, if a package maintainer asks for testing and the ability to keyword (i.e. Spanky asking me if it was OK to bump binutils to 2.16, to which I said yes) then that is fine. However adding or changing keywords in an ebuild for which you cannot test (regardless of how trivial the changes are or how portable the programming language of said package is supposed to be) is really where I'm looking at here. Wouldn't it be better from a QA perspective to go back to the (really) old policy of dropping anything you can't test on. I know that puts more work on you guys, but this is only going to get worse as we get more devs. Wouldn't it be better to nip this in the bud now. Maybe broaden the arch teams by giving some devs access to remote boxes. --Or-- Get every dev access to all the supported arches (some of this could probably be done with emulators of some sort, qemu or somesuch). Make them test on every arch before they change any keywords. --Iggy For some odd reason, trying to ensure QA (even in the nicest of fashions) seems to result in a majority of less than positive responses. Even recently I've had a developer get quite confrontational with me over email when I nicely asked him not to stabilize packages for which he could not test (even if the changes were supposedly trivial). History has shown that we cannot depend on assuming that trivial changes for me == works for you if we want to have some level of Q in QA. Cheers, - -- Jason Wever Gentoo/Sparc Co-Team Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Using OpenAFS volumes as storage for various portage directories
Kevin wrote: snip Does anyone have any thoughts to share on: a) general advisability of this (seems like a good thing to me---lots of savings on space across machines, oafs has a good authentication system in kerberos, seems better to me than running a local rsync server alone and also better in at least some ways than NFS, etc), b) what special considerations I should keep in mind with such a scheme, c) security, d) general reading material to help me think about a-c better. Sounds like you have a couple of Gentoo boxes there. You may want to look into a recent feature that was added. /etc/make.conf now supports the source keyword like shell scripts. You can have a network wide make.conf that you include on all your hosts. Then override whatever needs it. That's all the input I have since I know nothing about afs. --Iggy TIA. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, 2005-05-02 at 20:58 -0400, Alec Warner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Jackson wrote: Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't install everything for pkg FOO in ROOT=/opt fex. Mostly useful for alt arches when /usr is taken by the primary OS and you need portage's DEPEND packages to go somewhere else. Well, I've got a bug open to have a different variable like ROOT that portage would read config files from. Maybe you could jump on that bandwagon, and see if you can make things work that way. I just don't see the uptake to fix a very large portion of the tree for something that I'd guess most devs think is pointless. That's also the reason the enterprise tree hasn't taken off. People working in their free time couldn't give a crap about people thinking Gentoo isn't suitable for enterprise applications. In fact, I'd bet there are even some people that already do or would sabotage such an effort. If you want to use portage, use Gentoo. If you want some package manager for your solaris/x86 box(just an example!), go talk to the people that do openembedded. They are geared toward using it as a secondary package manager on a system. --Iggy -- gentoo-dev@gentoo.org mailing list
