Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Paul de Vrieze <[EMAIL PROTECTED]> writes: > It is also needed for third party apps that were linked against > libstdc++.so.5. As long as those applications do not depend on other > libraries that are linked against a newer c++ lib things are totally ok. But unfortunately is does happen. For example on my system (~x86 built with gcc 3.4.4) opera is linked against libstdc++.so.5 and libqt-mt.so.3 which in turn is linked against libstdc++.so.6 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
[EMAIL PROTECTED] writes: > Again, would anyone know what will happen to ~x86 gcc?, Will it become > gcc40 or just use the stable x86 gcc for everyone? (except those who are > already playing with gcc40 at their own risk) Even if ~x86 does change to gcc40 then gcc is slotted so we can continue to use gcc3.4.4. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Let portage symlink latest version of installed docs
Fabian Neumann <[EMAIL PROTECTED]> writes: > What I'd like portage do to is to create a symlink to the latest version > of a package's documentation. Just omitting the version number would of > course not work as slotted packages may have multiple versions of docs > installed. The first format coming to my mind would be: What would be even nicer would be if it could create and maintain an html index, for example at /usr/share/doc/index.html, to all package html documentation in a similar way to that which gnu info maintains the top level index to all info documentation on the system. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Alec Warner <[EMAIL PROTECTED]> writes: > The only downside afaik, for bashrc is that you can't do per package > FEATURES as FEATURES is a python-side var. But you shouldn't need > per package FEATURES by design; FEATURES are for portage, not your > ebuild. >From the perspective of a user, not a developer (though I have been a programmer for over 25 years), it would sometimes be useful to set some features on a per package basis rather than globally. These include binpkg, nostrip, splitdebug and test. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] config_eth0 deprecated - new name?
Roy Marples <[EMAIL PROTECTED]> writes: > On Wednesday 23 April 2008 21:46:18 Robin H. Johnson wrote: >> See my attached example from work, we use a lot of the various options >> on stuff. > > No, we won't support that. However, we will bring back ip ranges for the last > ocet like so > 1.2.3.4-10/24 It looks to me as though you are intending to remove the capability to set up complex network environments. Granted most people only have simple configurations (with single IP address and just a default route), but some of us have more complex networking environments with multiple addresses, routes and rules on multiple interfaces. Currently Gentoo baselayout-1 makes it relatively straightforward to set up these configurations, and the current baselayout-2 is almost as simple[1]. I think it would be a bad idea to remove any of the network configuration functionality currently offered by baselayout-1. [1] But in my opinion, the baselayout-1 /etc/net.conf syntax is better than that in baselayout-2. Though I have not yet migrated any of the systems with complex networking to baselayout-2. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] config_eth0 deprecated - new name?
Roy Marples <[EMAIL PROTECTED]> writes: > On Wednesday 23 April 2008 23:01:38 Graham Murray wrote: >> It looks to me as though you are intending to remove the capability to >> set up complex network environments. > > No I'm not. > I'm making it easy for simple configs AND complex ones. Just not through the > same variable. Sorry, I misunderstood. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: > USE=cxx should do just fine, it will disable the C++-related parts, > whatever they are. Sincerely I'd quite like to enable it on my vserver's > build chroots too. Should that be USE=-cxx? The help for USE=cxx says that this builds support for C++. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [EMAIL PROTECTED]
Ciaran McCreesh <[EMAIL PROTECTED]> writes: > * dismiss any technical criticism as being a 'corner case'. And not appreciate that addressing the 'corner cases' is very important and not to be dismissed. I have been a software developer (though not a Gentoo one) for 30 years, and learnt that lesson a long time ago. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI 2 policy for portage tree
"Robert R. Russell" <[EMAIL PROTECTED]> writes: > 3) perform the bugfix with a version bump and upgrade to the latest EAPI > Options 1 and 2 are how most updates are done, the user can mask the latest > version or upgrade. Option 3 allows the user to continue using the previous > version while they decide to update to a portage version that supports the > new EAPI. > > I would prefer that option 3 be made policy because I run several ~arch > packages that either don't have a stable version (kradio) or have a feature > that I need (gentoo-sources), and will not be pushed to stable immediately > for various reasons from lack of maintainer time to everybody says it > conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, > and xorg). Another reason for preferring option 3 for bug fix (but not for 'cosmetic' changes or ones which prevent some users from installing the package) is that (~arch) users will already have the pre-bug fixed version installed and portage will not install the bug fix unless either the version is bumped or USE flags have changed and the --newuse emerge option is used.
Re: [gentoo-dev] rfc: location of portage tree
"Walter Dnes" writes: > On Thu, Mar 29, 2012 at 10:26:22PM +1300, Kent Fredric wrote > >> Though of course, if anybody has custom stuff in say, /usr/portage/local/ >> which they make by hand, nuking /usr/portage will make you *Very* >> unpopular. > > > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part3_chap5 > in the install handbook gives "/usr/local/portage" as an example overlay > directory. I thought it was implicit that one shouldn't edit or create > files in /usr/portage because they may be overwritten by the system e.g. > during an "emerge --sync". Maybe the manual needs to state this > explicitly. Also, /usr/local is the "standard" place to keep one's own > software and/or global customizations that aren't handled by the package > manager, but don't belong in one user's home directory. Where using /usr/portage/local is useful is for 'site local' packages. Where one system syncs externally and also has all of the locally generated/edited packages in /usr/portage/local, and the other systems share this site local repository simply by running "emerge --sync" to the 'master' system.
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Sascha Cunz writes: > You've said yourself, that "some removable media might not require > signatures" > in order to boot. Well, if that is the case, then isn't this defeating the > whole point of Secure Boot at that stage? Not necessarily. As has been stated previously, secure boot is not intended to protect against an attacker who has physical access. So even if allowing boot from removable media, it does protect against malware which corrupts/infects the hard drive boot image.
Re: [gentoo-dev] Re: udev <-> mdev
"Walter Dnes" writes: > On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote >> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao wrote: >> > mdev would need to switch to the netlink hotplug interface. >> >> I think that's quite unlikely, since mdev is not a daemon. Perhaps by >> the time /proc/sys/kernel/hotplug is gone, mdev advocates will have >> settled on some early udev fork. [1] > > Do you realize this would effectively kill linux in the embedded > device area? Udev, even without the systemd code, is simply to large > for embedded devices. But surely most embedded devices do not need hotplug functionality, they have a known, fixed, set of devices. So should static nodes in /dev/ not be sufficient?
Re: [gentoo-dev] Re: Maintainer needed: dev-libs/icu
Ryan Hill writes: > Christ on a $#@%! crutch. You can NOT auto-enable C++11 in your library based > on a configure test and then stuff flags that are not supported by previous > compiler versions into pkg-config for library consumers. Somebody sane > please fix this. Though is it not normally a reasonable assumption that the library consumers will be built with the same or later compiler version as the library? In which case it does no harm.
Re: [gentoo-dev] [RFC] Global USE=gui
waltd...@waltdnes.org writes: > Let me re-phrase my question... is there *ANY* set of circumstances > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag > can be set for a package *WITHOUT* requiring a gui? Yes. X/xorg could be needed to incorporate the X Client libraries so that X servers can connect to it but not itself have a gui. This could, for example, be on a headless server.
Re: [gentoo-dev] Moving our/portage stuff to var
Zac Medico writes: > On 12/19/2012 02:01 PM, Alan McKinnon wrote: >> If we are going to move distfiles out of the tree into, what are the >> odds of getting /some/path/portage/local to move somewhere else too? > > What program uses this "local" directory? It's not used directly by > portage itself, though portage has an exclude for it in the default > PORTAGE_RSYNC_OPTS setting (in /usr/share/portage/config/make.globals). It is useful for 'site' local ebuilds. It allows a 'master' repository to sync with the main Gentoo one without disturbing local changes but allow other systems on-site to fetch the modified tree with a simple 'emerge --sync'.
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
Peter Stuge writes: > Kernel -sources USE is a handy way to install linux-firmware > wholesale, but AIUI the standalone firmware packages would > be removed too, effectively making the USE flag non-optional, and > removing the possibility of having managed firmware packages. > (People would have to download single firmware files on their own.) What would perhaps be nice would be to patch 'make firmware_install' to have it call a utility which scans .config and fetches and installs any firmware required for a configured device.
Re: [gentoo-dev] Re: unicode and userlocales useflag
"Duncan" <[EMAIL PROTECTED]> writes: > There's a newer way to control the same thing that userlocales controlled, > but I didn't understand it when it was posted here. Though, AFAIK, there is no way of retaining the old behaviour, of building all locales, when the local userlocales flag was not set. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Martin Schlemmer <[EMAIL PROTECTED]> writes: > Stupid question though ... does the gcc test thingy list __3dNOW__ on > nocona ? I would think that it does, as there is no -march=nocona (or > whatever) yet. There is an -march=nocona (which I think was introduced in gcc 3.4) which works for both 32bit (x86) and 64bit (amd64) systems. At least on x86 it does NOT define __3dNOW__. Also, for x86 -march=prescott defines __SSE3__ whereas -march=pentium4 does not. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ethereal moved to wireshark
Daniel Black <[EMAIL PROTECTED]> writes: > Ethereal, as far as anyone can tell, is no longer being developed[3] as all > the core developers have moved to Wireshark[4]. > > To make this transition as painless as possible, a package move has been > setup > so Ethereal users should automatically upgrade to Wireshark. Is there an equivalent of (or replacement for) the command line tethereal? This can give more useful information than tcpdump and can be run in real-time on servers over an SSH connection. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ethereal moved to wireshark
Chris Gianelloni <[EMAIL PROTECTED]> writes: > On Tue, 2006-07-25 at 16:16 +0100, Graham Murray wrote: >> Is there an equivalent of (or replacement for) the command line >> tethereal? This can give more useful information than tcpdump and can >> be run in real-time on servers over an SSH connection. > > tshark... =] Thanks -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect module for choosing between gnash and netscape-flash
[EMAIL PROTECTED] writes: > I wrote an eselect module for choosing between the browser plugins from > net-www/gnash and net-www/netscape-flash, and I was wondering if it could > be included in Gentoo (probably not in its current state...). Would it also be useful to have something similar for selecting whether, for example, gxine or mplayerplug-in plugins are used for the various multimedia MIME types? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuild documentation, needs updates?
Alec Warner <[EMAIL PROTECTED]> writes: > This feature is not available in stable portage, which is why its not > documented. And yes there are many other features that lack > documentation. But should it not be documented in the ebuild man files which come with the versions of portage which *do* support the feature? I know that it is not always done, but when new features/switches/options are added to any program, should the man (or info, pod etc) file not be updated to include them? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
Roy Marples <[EMAIL PROTECTED]> writes: > H, just how many features should a config file have beyond the > setting of variables? In the case of networking, the ability to define the functions for the various hooks. In most systems these will not be needed, but where policy routing etc is used the hooks need to be defined somewhere, but not necessarily the configuration file as they are at the moment. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Distrowatch
"Caleb Cushing" <[EMAIL PROTECTED]> writes: > right now were 12 going up probably from all the sites saying > negative things. funny sabayon a gentoo fork and overlay is in 8. I > know these statistics aren't 100% accurate (given how they're > generated) but maybe they mean something. Maybe part of the reason is that the list of package versions for Gentoo on distrowatch is inaccurate. For example it gives the versions of gcc and glibc in 'unstable' as 3.4.6 and 2.3.6 respectively when the actual versions are 4.1.2 and 2.5 respectively. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gnupg2 only vs gnupg-1 & gnupg-2
Ulrich Mueller <[EMAIL PROTECTED]> writes: > I would also strongly favor if both gnupg-1 and gnupg-2 could be kept > in different slots. And maybe an eselect (or similar) to select whether external programs which call use gpg-1 or gpg-2. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Marking virtuals stable
"Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> writes: > for a virtual pointing to packages foo and bar, only one of them needs > to be stable before the virtual can be marked as stable, right? > So your above comment should read "if a virtual points to packages foo > and bar, and [either foo or bar was] tested and marked stable by the > arch's previously, that its silly to then wait for them to mark the > virtual stable as well", right? At first sight what you say sounds right, but further thought shows that both foo and bar would have to be marked stable before the virtual could be. Take the instance that the appropriate version of foo is marked stable but that for bar is still in ~arch. If someone has foo installed then upgrading the virtual will pull in the new (stable) foo and all is well. However if someone else has bar installed but not foo, then the upgrade to the virtual will not cause bar to be upgraded (as it is still masked ~arch) but will cause the upgraded foo to be installed (as a new package) to satisfy the virtual. Or have I (as a mere user) misunderstood the concepts of virtuals? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
Roy Marples <[EMAIL PROTECTED]> writes: > If say you have nfs mounts, one network cable and then unplug the cable > you get this :- >netplug calls net.eth0 stop >net.eth0 stop calls netmount stop >netmount stop tries to unmount the nfs mounts > At this point, the process freezes for a LONG time that can't be > interupted because as the cable has already been unplugged it can't > unmount (if anyone knows how to actually return ASAP I'd like to know > that too). > With the default to NO the act of pulling the cable simply stops > net.eth0 and the services stay up and things continue nicely. To avoid that problem, do not stop net.ethN when the cable is pulled. When the cable is re-inserted then (if it has not been left disconnected for too long) if the services have not stopped, TCP sessions may still be active. If the user manually stops an interface, by all means stop the services depending on it but (a) Do not make the interface stop automatically when the cable is disconnected, (b) It would be nice if there was a single command which could restart all the dependencies which were stopped. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
Mike Auty <[EMAIL PROTECTED]> writes: > Could you please describe the problem you faced? From the detail you > gave, it sounds as though you might not have moved /etc/conf.d/cryptfs > to /etc/conf.d/dmcrypt. I had a problem. I moved /etc/conf.d/cryptfs to /etc/conf.d/dmcrypt, but none of the encrypted mounts happened on re-boot. I found that running 'cryptsetup luksOpen /dev/hhh mountname' segfaulted (but cryptsetup --help displayed help). But when I ran it using gdb (and using set args to set the identical command line) it worked correctly. I will be investigating more later, but for now I have re-emerged cryptsetup-luks 1.0.4-r3 and all works well again. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Global useflag for enabling visibility support
Piotr Jaroszyński <[EMAIL PROTECTED]> writes: > I think it's time to add a more general flag for enabling visibility support > in packages as currently there is only a kde specific one > (kdehiddenvisibility) and I don't think it makes sense to add a new one for > each package that needs it. Some packages, such as mozilla-firefox, enable visibility support without the use of a USE flag. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
Branko Badrljica writes: > 2. About using bugzilla- how the heck was I supposed to use it without > net access ? If openrc did not start your networking, what was preventing you starting it yourself? Even if the upgrade also corrupted both sys-apps/net-tools and sys-apps/iproute2[1], you could have booted from a rescue/install CD/DVD/USB stick[2]. [1] Which I very much doubt. [2] Which I have had to do a couple of times when the system would not boot following an update or change I have made.
Re: [gentoo-dev] sudo vs su
Denis Dupeyron writes: > Some systems are configured with a random root password. After a while > you get tired of doing 'sudo ' all the time and would like to > become root but you can't because you don't know the root password. > One way around that is 'sudo su -' which allows to become root using > your user password. When I had to do this on a (RHEL) system, I did not think of using 'sudo su -', I used 'sudo bash'.
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
Richard Freeman writes: > I think that is separate from the circular dependency issue. As long > as we have an unresolved circular dependency I think cups should be > off the list. However, I'd be the first to agree that this is a > short-term solution. > > The problem is that we only have two long-term solutions so far: > > 1. A smarter package manager that can work through these dependencies > automatically. > > 2. Splitting packages like poppler that have these issues. Is there not a third, maybe obvious, solution to circular dependencies on initial install? 3. Include one or both of the packages in the stage tarball.
Re: [gentoo-dev] About libpng-1.4 handling
Mike Frysinger writes: > if you're "digging around" then clearly you havent done the obvious and run > revdep-rebuild ? that is pretty user-friendly. I do not know if I had done something wrong beforehand, but "simply" running revdep-rebuild did not work for me - a number of packages failed to rebuild during the revdep-rebuild. They were still failing to find libpng12 during the rebuild while doing gtk-doc scan. In every case, manually unmerging the package concerned and re-emerging it was successful. It is as though it was using the scan (which needed libpng12) from the already installed package in preference to the one it had built in /var/tmp/portage/...
Re: [gentoo-dev] About libpng-1.4 handling
George Prowse writes: > I have run revdep-rebuild about 30 times and I still can't fix > it. revdep-rebuild does not fix it and libpng needs to have some > serious action before it goes stable because I booted into, basically > a completely broken machine because I had to stop a large upgrade on > the previous emerge (~300 packages) in the middle. Are the failures during a gtk-doc scan? If so then try unmerging the affected package and then manually re-emerging it.
Re: [gentoo-dev] bug wrangler queue is large...
Mike Frysinger writes: > the bug reporter can open their own bugs. gentoo developers can open any > bug. > that's about it. Which can be a pain for other users who suffered the same bug (and are probably on the CC list), the maintainer says to re-open if the problem is not fixed, the user finds the problem is still there but the bug reporter does not re-open the bug. All you can do is add a comment and hope that a developer sees it and re-opens the bug.
Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*
Thomas Sachau writes: > Since python-3* is currently useless and not required for any package, the > dependency should by > default only pull in python-2* like this: > > =dev-lang/python-2* > > With that, the default way would not pull in a package, which is not needed > or used. And if there > will be any package, which really requires python-3*, it simply requests it > in (R)DEPEND of the > ebuild, which then would overwrite the default value of the eclass and pull > in python-3*. That would not work. For example if package 'bar' supports both python-2 and python-3, your mechanism will only build in python-2 support. That is fine until package 'foo' comes along which uses 'bar' but also requires python-3 - thus not only must python-3 be pulled in as a result of foo's (R)DEPEND but also 'bar' must be rebuilt with python-3 support. This could be done by adding python2 and python3 USE flags to packages which support both and only have python2 enabled by default. Then 'foo' could have a conditional (R)DEPEMD on 'bar[python3]', but that would require the user to change the USE flags whereas the current system handles everything automatically.
Re: [gentoo-dev] reply-to munging
Andrea Barisani <[EMAIL PROTECTED]> writes: > Starting a poll on *forums* about a *ml*, no thanks :). Hope you were being > sarcastic. I'm open to suggestions other than the "remove the header and let > the > flames come" option which unfortunately looks like the only one to me and > despite being "right" in many regards I fear it will cause the havoc that > we've experienced on gentoo-user. One problem with that approach is that someone who does not like the change is far more likely to send a 'complaint' than someone who likes the change is to send a 'thank you'. I suspect that such flaming often comes from a vocal minority and does not represent the views of the majority of list members. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: have_NPTL proposal/question
R Hill <[EMAIL PROTECTED]> writes: > the only thing i know of that needs LT is Xen, and they're already > working on NPTL support. Also the (user space) driver from Epson for the Stylus Photo R800 printer needs Linuxthreads. While much of this is available in source code form, it includes a couple of binary libraries. These do not work correctly using NPTL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: app-portage/genlop: 9 open bugs, dead upstream
Michael Cummings <[EMAIL PROTECTED]> writes: > The funny thing about no more activity upstream is this: why would > there be? Except for bug fixes, it does a simple job, and it does it > damned well: it parses your emerge log and gives you just the output > you want and need. Don't abandon a tool just because it has reached > its final state ;) Except that at the moment it does not do it well as it does not work with the '-c' option - as reported in bug 99823 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
Mike Frysinger writes: > well, not quite. the way we agreed in the past was to not revbump the masked > package, but once it was unmasked, we revbump it just once at that point. Is there somewhere which tells users when there are upgrades to toolchain packages which are not revbumped once they have been unmasked and in ~arch? A case in point, glibc-2.12.1-r3. When I rebuilt this following the merging of linux-headers-2.6.36, the rebuilt downloaded about 700K of patches.
Re: [gentoo-dev] Python 2.7 status check?
Arfrever Frehtes Taifersar Arahesis writes: > 2010-11-29 01:26:19 Robin H. Johnson napisał(a): > Sebastian Pipping recently removed automatic upgrade of active version of > Python, so > python-2.7.1.ebuild does not upgrade active version of Python. Sorry, but on one of my ~x86 systems the installation of python-2.7.1 DID update the active python version to 2.7. Worse than that, now python-updater is running it is removing all of the usr/lib/python-2.6/site-packages/ files and for multi-version aware packages only building for python-2.7 & 3.1, it is NOT building for python-2.6.
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller writes: >> On Mon, 29 Nov 2010, Alex Alexander wrote: > > I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which > until two days ago unconditionally called the following eselect > action: But as python-2.7 is installed into a new slot, python-2.6.x is kept, so python-2.6.6-r1's pkg_postrm() should not be called.
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller writes: > I guess it is triggered from pkg_postrm() of python-2.6.6-r1 which > until two days ago unconditionally called the following eselect > action: But python-2.7 is installed in a new slot and python-2.6.x is not removed. So. surely python-2.6.6-r1's pkg_postrm() should not be called during the installation of python-2.7.1.
Re: [gentoo-dev] Python 2.7 status check?
Ulrich Mueller writes: > But could pkg_postrm() of python-3.1.2-r4 have caused the update? > It essentially executed the following code: Yes, that is what is doing it. I am in the middle of an emerge -uD world and I ran 'eselect python list' after 2.7.1 had been emerged and it still showed 2.6 as being the active. But after 3.1.3 had been installed, it shows 2.7 as being the active version.
Re: [gentoo-dev] Re: Thoughts about broken package handling
Ciaran McCreesh writes: > The fix for that is to slot things properly. You're screwed anyway if a > preserved library tries to access installed data that has either been > removed or upgraded to a new format that it doesn't recognise. Or some "awkward" packages which when rebuilt will still link against the preserved library, but if the preserved library is deleted and the package manually rebuild will link against the new one.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Chí-Thanh Christopher Nguyễn writes: > My point is that packages can cause downgrades through "<" dependencies. > There is no rule against it. Nearly all of which prevent the upgrade of the dependent package rather forcing the downgrade of an already installed package.
Re: [gentoo-dev] Build dependencies and upgrades.
Zac Medico writes: > On 10/11/2011 10:28 PM, Mike Gilbert wrote: >> Francisco raised a possibly valid point in his original message: though >> packages may not be currently used for anything, but they could contain >> un-patched security flaws. > > If they contain something that's accessed at runtime, then they should > be in RDEPEND or PDEPEND, no exceptions. But is it not possible that the flaw in the build-time dependency causes an insecurity to be built into the dependent package and that both have to be rebuilt as part of the security fix?
Re: [gentoo-dev] supporting /usr on separate partition
Zac Medico writes: > What's the benefit of having /usr on a separate partition anyway? The > only somewhat reasonable explanation that I've heard is so that it can > be mounted readonly. One benefit, especially in a large server 'farm' is that several servers can share the same /usr by NFS mounting, read-only, the same partition on all of the servers. This both ensures that all the servers are kept in-step and greatly simplifies the upgrade process.
Re: [gentoo-dev] Keeping older versions around
Donnie Berkholz writes:
> Agreed with a slight modification — once you've kept the old
> {stable,~arch} version around for a reasonable amount of time (say 30
> days), you should be safe pulling it.
As long as there are no open bugs on the later ~arch version breaking
other packages.
