[gentoo-dev] last rites: dev-java/jdictrayapi
# Michael Sterrett (10 Dec 2013) # Dead upstream; requires java-1.5; open bugs: # https://bugs.gentoo.org/show_bug.cgi?id=196522 # https://bugs.gentoo.org/show_bug.cgi?id=241512 # https://bugs.gentoo.org/show_bug.cgi?id=355055 # Masked for removal on 20140109 dev-java/jdictrayapi
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina wrote: > I really don't like the idea of having no networking in the stage3 by > default, however, I'm becoming more open minded on what qualifies as > networking. What I'm wrestling with is this, what if I want to slap a > stage3 on a device and then access it from the network? Hit your head on the wall because it doesn't contain a kernel? Stage3s in general aren't functional systems. > I really feel that while the rest of the world is trying to get > more functionality out of their hardware we are trying to save ~200k and > possibly crippling user experience in the process. The rest of the world would just stick systemd, dbus, pulseaudio, xorg, an initramfs, every kernel module under the sun, ndiswrapper, 300 windows driver blobs, and a network manager that uses gtk+ to configure your network on the stage3. That is how they get more functionality out of their hardware. It just isn't the Gentoo way. :) > > Is removing ~200k really worth the potential downside? Honestly, if we > are going on the merits of smaller downloads let's argue about using xz > instead of bzip2 for the stages... I'm not concerned about space use at all. I think the main argument for leaving oldnet on the stage3s is that it doesn't do anything if you don't symlink it, just like openssh. If it actually had collisions with other network managers I think there would be more of a case for removing it. Rich
Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
On Mon, 9 Dec 2013 17:19:34 +0100 Ulrich Mueller wrote: > > On Mon, 9 Dec 2013, Rich Freeman wrote: > > > If you think that B isn't the empty set, it is trivial for you to > > demonstrate that this is the case. Simply give me a single example > > of a situation where: > > 1. It makes sense for a dep to use a new slot. > > 2. It makes sense for all of its reverse deps to automatically use > > the new slot without any further intervention by the individual > > reverse dep maintainers. > > app-editors/emacs, to start with. > > If you go through the list of about 400 packages that have more than > one slot (out of 17000 packages in the portage tree), I'm sure you'll > find many more that fall in B. On first glance, only a minor part of > these 400 seem to be libraries. It is surprising that there are only ~400 packages that have multiple slots available in the Portage tree; trying to reproduce this, I get a similar number. Out of a ~350 total, ~75 contain "libs/", ~100 contain "dev-java/" (almost a third); there's are some ruby and haskell libs too. These groups are almost all libraries, so it somewhat fifty-fifty. Note how Java packages already have a project policy to explicitly specify slots on dependencies; as the eclass functionality relies on that. As a consequence, it is easy to add a new slot to them. For the Java herd it makes total sense to use explicit slots that way. With new version bumps to reverse dependencies of dev-java libraries; it is interesting to note that as time goes by, you will eventually need to depend on the newer slot instead as upstream upgrades its support for that dev-java library; dropping support for the old version. But that's just a third and not necessarily representable, it can however show how it works in practice. Libraries' slot usage is harder to tell and needs a more thorough look as to how these are done. It's easier to tell by someone whom has more experience with how these libraries are versioned, seeing that most of these are media-libs and x11-libs I'll try asking the relevant herds. For applications (or should we say "all the rest") I think we need to look at which kind of packages these are and what the slots mean. For example, there are ~14 kernel sources that have multiple slots, which are as far as I know not used as dependencies; it just serves quite handy for the user to add it to the world file. There is also www-client/google-chrome and sys-boot/grub, those are packages where slots are meant for the user and not for reverse dependencies. What do you think? Does someone have a different view? Please share. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On 12/09/2013 10:50 PM, Rick "Zero_Chaos" Farina wrote: > On 12/08/2013 05:25 PM, William Hubbs wrote: >> On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote: >>> 1.) If we are going to stuff this into @system then we probably want a >>> USE=nonet flag to allow users to not pull anything in if they really >>> don't want it. > >> We don't have to put this in @system at all. We could just have a >> virtual/network-manager, like we have virtual/cron, virtual/logger, >> virtual/mta, etc. None of these are installed by default; you have to >> choose one as part of your installation process. The more I read this >> thread, the more I agree with this approach; let the user make the >> choice as part of the installation process. > >>> Just as a side note, after reading the thread up through this point, I'm >>> terrified of the individuals who wish to remove networking support from >>> stage3 entirely. If anyone wants to push that idea then that needs to >>> be addressed by the council. Period. Such a major change is going to >>> cause a holy war, and myself and others will actively revert any change >>> which removes net from stage3 under the guise of "critical breakage" >>> unless there is council direction that says we are no longer including >>> net support in the stage3s. > >> I am in agreement with Rich and Peter. This isn't a matter of breaking >> the stages; it is a matter of us getting out of the way and letting the >> users pick the network stack they want. We do this for the kernel, boot >> loader, etc, so I don't understand why you feel we need council >> direction to make a similar change for the network manager. > > > I am softening a bit, but I'm really concerned that the stages all of a > sudden not having net is going to be an issue for people. Maybe I'm > mistaken, but it is hard for me to imagine that moving to a stage3 with > no net anything is an improvement. I suppose you can't download a > stage3 without net, so you should typically be able to just chroot in... And again I point at the precedent of having dhcp in stage3, then removing it and people getting quite frustrated with having no way to enable net properly. We had the same type of problem before, and it was fixed. Why are we trying to break it again, just so we fix it a week later when the complaints become loud enough? > I can honestly say most of the time when setup my arm systems I'm > unpacking the arm stage3 on an amd64 and then booting the arm device > with the base stage3 and fixing things from there. I suppose it is > possible to use qemu to install things, as long as I don't mind > pretending it's 1999 due to the slow emulation speeds... Yeah, I really > don't see an improvement here. It works fine for "I'm an amd64 user and > that's all I'll ever use" but when you start talking about smaller > arches it really starts to become a hassle imho. > > -Zero >
Re: [gentoo-dev] Re: About pam herd status
On 12/09/2013 02:21 PM, Diego Elio Pettenò wrote: > I stopped caring about pambase when people decided to break it. > > I'm still officially pam herd as maintainer of Linux-PAM, pam_ssh I don't > use and care very little about. > > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > > > On Mon, Dec 9, 2013 at 2:20 PM, Pacho Ramos wrote: > >> Hello >> >> Is pam team still active? I wonder about this as, recently, we have >> needed to go ahead and fix some bugs related, for example, with pambase >> and pam_ssh >> >> Thanks for the info :) >> >> > So I guess it's time to call for maintainers or we should consider merging this herd with another one (base?) to avoid unattended bugs for a long time. -- Regards, Markos Chandras
Re: [gentoo-dev] python versioned libraries or not
On 08/12/13 00:44, hero...@gentoo.org wrote: > yac writes: > >> Shouldn't pkg-conifg --libs handle this? > > Oh, good idea. But boost doesn't have pkg-config entries. > > Then I see this one, an upstream issue > > https://svn.boost.org/trac/boost/ticket/1094 > Are you willing to poke upstream again? I'm not sure which problem they have with pkg-config that a little more awareness wouldn't solve. lu
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2013 10:28 AM, Rich Freeman wrote: > On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina > wrote: >> I can honestly say most of the time when setup my arm systems I'm >> unpacking the arm stage3 on an amd64 and then booting the arm device >> with the base stage3 and fixing things from there. I suppose it is >> possible to use qemu to install things, as long as I don't mind >> pretending it's 1999 due to the slow emulation speeds... Yeah, I really >> don't see an improvement here. It works fine for "I'm an amd64 user and >> that's all I'll ever use" but when you start talking about smaller >> arches it really starts to become a hassle imho. > > Ok, now the concern is becoming more clear. You're intending to boot > directly to the stage3 and not chroot into it, and so you want the > stage3 to be a fully-functional userspace, though you don't actually > need it to contain a kernel/bootloader. Correct > > How do you even log into the stage3? Do we not disable the root > password by default? No, we don't disable it. It's trivial to set without chrooting (steev has details in his response and that isn't he point of this thread) > > Can you boot off of the minimal install image instead? Not sure if we > have one of those for ARM. Actually, any boot image that sets up a > network and supports chroot would work fine for your purposes. I do > realize that many (all?) ARM platforms don't have a flexible > bootloader like x86 typically does - so I'll let you speak to what > makes sense here. Sadly no, again covered by steev in his response we don't off anything bootable for arm at all. > > Following the handbook, the network is established by the boot CD and > all you do before chrooting is copy over your resolv.conf. In that > environment there is no need to have a networking system pre-installed > on the stage3. Well hold on there... the handbook doesn't mention anything about emerging your choice of network manager just yet, and when everything including dhcpcd isn't in the stage3 you will need to do more than copy resolv.conf (which honestly I never do anyway) or it won't work very well. > > Oh, and if I'm not mistaken the stage3 is based on the system set > which is established by the profile, so if it made sense to keep > networking around for ARM that would be an option. > I grant this is an option, but what about guys like steev? He has a large stack of arm devices and like 1 amd64 box. What if he wants to put a stage3 on a disk for his amd64 box from his arm box? I'd love to see him emulate an amd64 from his arm to install dhcpcd. Now granted, that's being a little pedantic, as he could probably use one of the gentoo isos available to boot instead, but the point is we are removing software that gives the user a choice under the guise of giving the user a choice. I really don't like the idea of having no networking in the stage3 by default, however, I'm becoming more open minded on what qualifies as networking. What I'm wrestling with is this, what if I want to slap a stage3 on a device and then access it from the network? Almost nothing in my place has a monitor (amd64 and arm alike) and I use one of my two laptops to talk to everything else. Say I want to rebuild a headless machine, what am I supposed to do? Unpack a stage3, install some network manager manually (netifrc for me) and then boot? Granted, we already have to do this for any device which is wifi only as wpa_supplicant isn't in the stage3, but to remove this ability from wired devices as well I'm torn, I really don't think it's a great idea. I really feel that while the rest of the world is trying to get more functionality out of their hardware we are trying to save ~200k and possibly crippling user experience in the process. Is removing ~200k really worth the potential downside? Honestly, if we are going on the merits of smaller downloads let's argue about using xz instead of bzip2 for the stages... - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSpiBiAAoJEKXdFCfdEflKuWMP/j7S40wYWxGWbI34Ij2U5dSG l11wJYdAP0k9bLs4rhDvJG56EaTyBJJYvfDCz+W2XF01MyNcdQfH2BzqEifp0ZOD kI0x81xzIqpb4YC1KvJXQxStDvs1Nxp3KbCX+Jg2hdkMv4hlHR7NF/g1gUajC8eA 8tKdLcqIz822REqGtShGLYO9cjLaHZhGr/rFlxyK9ReQqj5cCdmEZ1MKN0Kb/DSa gQf+pmdecXXjCbF3N/5eihcQDrKe2UbXuKM/nNaiVw1ETnI+gjn815ofUNCc3Ynu jXZC4jse+MVQC6D6i3ZJi6o1VSlrGJmGDDxBSUtBPc7kSgFnaAz3AYC/izeIFtb9 VNQEmrcDjO5qKdZphc5ht2NW7uOBCZbpMoFmSj70cZK+NhJhaJPWqzUNu3mJLCUF 72W89HCC3oTbpPtMVQHz9F3nmzYhH+QfrEXGd96woTyjcsZYwXvY8UDm486gsdsR aGNJCN34RXQvsLrsJdxJWaHJex5w2UHkBsi5IQkJniD1grq+CModEWiaqfD6Fo/y WXT1LUr3/1cgsLFU3E5VhgdYl873z2oNUHisWR37XYDN/T3z4AZh1gEYUD30wILw vctPg/8dJAqcLQUkgqFvtAmlWeY/MPUaqpJLOkwcgN/Zmyw5LNfdyPH//5oT5G++ vYyFkaxsIzPnnAb5omme =6FAB -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Mon, 2013-12-09 at 10:28 -0500, Rich Freeman wrote: > Ok, now the concern is becoming more clear. You're intending to boot > directly to the stage3 and not chroot into it, and so you want the > stage3 to be a fully-functional userspace, though you don't actually > need it to contain a kernel/bootloader. > A stage3 is pretty much fully functional if you just create net.ethX and ln it in the default runlevel. (It will currently use busybox's udhcpc for dhcp client) > How do you even log into the stage3? Do we not disable the root > password by default? You can easily echo a password into /mnt/gentoo/etc/shadow - see code listing 5.4 on http://dev.gentoo.org/~armin76/arm/beagleboneblack/install.xml > > Can you boot off of the minimal install image instead? Not sure if we > have one of those for ARM. Actually, any boot image that sets up a > network and supports chroot would work fine for your purposes. I do > realize that many (all?) ARM platforms don't have a flexible > bootloader like x86 typically does - so I'll let you speak to what > makes sense here. We don't really have any minimal boot images for ARM as each device is different. Some devices have a u-boot that will boot an sdcard, some require you to put u-boot on the sdcard, some require a button press while having u-boot on the sdcard... so on and so forth. I'm not sure we really want to put out an image for each card (though it is something I'd like to discuss if the arm@ team would freaking reply to the thread on arm@ about having a freaking team meeting) > > Following the handbook, the network is established by the boot CD and > all you do before chrooting is copy over your resolv.conf. In that > environment there is no need to have a networking system pre-installed > on the stage3. > You can do this with a qemu chroot on an amd64/x86 machine - but as ZC mentioned, it's slow - really slow - qemu emulates an arm processor running about 200mhz slow, and really NOT ideal at all. I currently suffer through it to build wpa_supplicant as a lot of my arm devices use wifi, but it really sucks. Even building on an rpi is faster than through qemu. > Oh, and if I'm not mistaken the stage3 is based on the system set > which is established by the profile, so if it made sense to keep > networking around for ARM that would be an option. > > Rich >
Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
> On Mon, 9 Dec 2013, Rich Freeman wrote: > If you think that B isn't the empty set, it is trivial for you to > demonstrate that this is the case. Simply give me a single example of > a situation where: > 1. It makes sense for a dep to use a new slot. > 2. It makes sense for all of its reverse deps to automatically use > the new slot without any further intervention by the individual > reverse dep maintainers. app-editors/emacs, to start with. If you go through the list of about 400 packages that have more than one slot (out of 17000 packages in the portage tree), I'm sure you'll find many more that fall in B. On first glance, only a minor part of these 400 seem to be libraries. Ulrich
Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
On Mon, Dec 9, 2013 at 5:55 AM, Tom Wijsman wrote: > For the dependency syntax, having :* as a default breaks things or > causes a lot of work. If explicit slots (or :0) were the default, it > works and you spare out dealing with lots of reverse dependencies when > you introduce a new slot. I was giving this some more thought and here is another way of looking at this. Let A be the set of all situations where it makes sense to create a new slot for a package that has reverse dependencies. Let B be the subset of A where it makes sense for those reverse dependencies to automatically use the new slot without any intervention by the reverse dep maintainers. If |B| >> |A \ B| then the current default makes sense. (That is, if the number of elements in B is much larger than the number of elements in A that aren't in B.) If |B| << |A \ B| then it would make sense to require all slot dependencies to be explicit, and the ":*" dependency to be frowned upon in general. I think that the above just makes sense if you think about it, so I'll use that as my initial premise for what follows. By all means challenge this. So, what I'm going to do now is speculate that B = ∅ (that is B is the empty set). Therefore, it makes sense to get rid of the current default and require all slot deps to be explicit. If you think that B isn't the empty set, it is trivial for you to demonstrate that this is the case. Simply give me a single example of a situation where: 1. It makes sense for a dep to use a new slot. 2. It makes sense for all of its reverse deps to automatically use the new slot without any further intervention by the individual reverse dep maintainers. I can't think of any, and I'm all ears if somebody else can. It seems to me that our current default optimizes for a situation that is dubious from a QA standpoint. Its main virtue is that you don't have to go look up what the current slot is for slot-less packages, but honestly if you just stuck a :0 on every line of your ebuild chances are it would work on the first install and at least the behavior would be consistent for anybody else who uses it. Rich
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina wrote: > I can honestly say most of the time when setup my arm systems I'm > unpacking the arm stage3 on an amd64 and then booting the arm device > with the base stage3 and fixing things from there. I suppose it is > possible to use qemu to install things, as long as I don't mind > pretending it's 1999 due to the slow emulation speeds... Yeah, I really > don't see an improvement here. It works fine for "I'm an amd64 user and > that's all I'll ever use" but when you start talking about smaller > arches it really starts to become a hassle imho. Ok, now the concern is becoming more clear. You're intending to boot directly to the stage3 and not chroot into it, and so you want the stage3 to be a fully-functional userspace, though you don't actually need it to contain a kernel/bootloader. How do you even log into the stage3? Do we not disable the root password by default? Can you boot off of the minimal install image instead? Not sure if we have one of those for ARM. Actually, any boot image that sets up a network and supports chroot would work fine for your purposes. I do realize that many (all?) ARM platforms don't have a flexible bootloader like x86 typically does - so I'll let you speak to what makes sense here. Following the handbook, the network is established by the boot CD and all you do before chrooting is copy over your resolv.conf. In that environment there is no need to have a networking system pre-installed on the stage3. Oh, and if I'm not mistaken the stage3 is based on the system set which is established by the profile, so if it made sense to keep networking around for ARM that would be an option. Rich
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2013 05:25 PM, William Hubbs wrote: > On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote: >> 1.) If we are going to stuff this into @system then we probably want a >> USE=nonet flag to allow users to not pull anything in if they really >> don't want it. > > We don't have to put this in @system at all. We could just have a > virtual/network-manager, like we have virtual/cron, virtual/logger, > virtual/mta, etc. None of these are installed by default; you have to > choose one as part of your installation process. The more I read this > thread, the more I agree with this approach; let the user make the > choice as part of the installation process. > >> Just as a side note, after reading the thread up through this point, I'm >> terrified of the individuals who wish to remove networking support from >> stage3 entirely. If anyone wants to push that idea then that needs to >> be addressed by the council. Period. Such a major change is going to >> cause a holy war, and myself and others will actively revert any change >> which removes net from stage3 under the guise of "critical breakage" >> unless there is council direction that says we are no longer including >> net support in the stage3s. > > I am in agreement with Rich and Peter. This isn't a matter of breaking > the stages; it is a matter of us getting out of the way and letting the > users pick the network stack they want. We do this for the kernel, boot > loader, etc, so I don't understand why you feel we need council > direction to make a similar change for the network manager. I am softening a bit, but I'm really concerned that the stages all of a sudden not having net is going to be an issue for people. Maybe I'm mistaken, but it is hard for me to imagine that moving to a stage3 with no net anything is an improvement. I suppose you can't download a stage3 without net, so you should typically be able to just chroot in... I can honestly say most of the time when setup my arm systems I'm unpacking the arm stage3 on an amd64 and then booting the arm device with the base stage3 and fixing things from there. I suppose it is possible to use qemu to install things, as long as I don't mind pretending it's 1999 due to the slow emulation speeds... Yeah, I really don't see an improvement here. It works fine for "I'm an amd64 user and that's all I'll ever use" but when you start talking about smaller arches it really starts to become a hassle imho. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSpdiZAAoJEKXdFCfdEflKQ4kP/1RRWpXE2rN0Y74c9GW24l7W G3oFLQABgFd+8Osq+bKhFaY6uQ0pmV5Cz+a1cj9fa0LnyCumiEL+k+Z6LnuCdqat rZCQugvP3shvcWYVxKPjR6FEfXjGE8cPm+C32vV9oo0sDfAwjcflYFrXoeTTF07E Tp/r318TllEQ50KdeLzD9uBBxePFFClygYvppVEWfNUbSSWiB+rkvN2dF6LDCLBi lpYsozOEpRAoyCQYePQ/eo6iRHmWu39iq4qARek3UXKvZk6h+4qr4/EVtrG3v0A1 0d9mmMAySDQwLPR+CrpN19MD+4qgFjPPIVmdfG5sSU4CM3jf4elap55X6aircWzf m1CsIPxaBmOicNUNr3OMPn1vr/Sufd1jgC6wwaZRp77POqlpzEqKM9y6JCkF7xy8 2z8Enl7TvwIzre4f7qK7u/HXSvaUX8F97TI09XkzuMlrk69WMMzsmxLtngZy0I96 egKCsGsKKF8k0biolM0hav4R7RPTVdK+/3U6SJwF+QSTZay/dyQpG4543reNuarr y8uoeIrXA03RE71BRBeRArgBeR7PpoUld59IP+XzCdCWb5GqZYAuE7zmfFvvctnk Z+M3KhwSzyqA8Pie6YTTlTyBl7uyr6Hqs0vfiP14ctVKtIkiayE8Q2XjW9i+zODA EjwJy84Q3uQXjU2kxIDU =WYkG -END PGP SIGNATURE-
Re: [gentoo-dev] Re: About pam herd status
Am Montag 09 Dezember 2013, 14:21:17 schrieb Diego Elio Pettenò: > I stopped caring about pambase when people decided to break it. > link please? -- Andreas K. Huettel Gentoo Linux developer kde, council signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: About pam herd status
I stopped caring about pambase when people decided to break it. I'm still officially pam herd as maintainer of Linux-PAM, pam_ssh I don't use and care very little about. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On Mon, Dec 9, 2013 at 2:20 PM, Pacho Ramos wrote: > Hello > > Is pam team still active? I wonder about this as, recently, we have > needed to go ahead and fix some bugs related, for example, with pambase > and pam_ssh > > Thanks for the info :) > >
[gentoo-dev] About pam herd status
Hello Is pam team still active? I wonder about this as, recently, we have needed to go ahead and fix some bugs related, for example, with pambase and pam_ssh Thanks for the info :)
Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
On Mon, 09 Dec 2013 10:52:15 +0400
Sergey Popov wrote:
> In short - please do NOT do this.
Why not? What about other solutions? What do you think?
There have come up several solutions, the one suggested in the first
mail is no longer of interest due to SLOT="0" no longer being special;
now ideas tend to focus towards disallowing slot-less dependencies, or
otherwise implement under the form of a repoman warning.
> More complicated answer - you break
> the whole idea of slots. When user types 'emerge cat/foo' it means
> now - "i want cat/foo, whatever versions it will be(depending on mask,
> keywords, etc, etc)". Your proposal changes this behaviour
> drastically, and reasons for such changes are not worth it.
A package ATOM used in another place warrants another discussion; when
an user types it, what does the user mean? We could opt to not change
the behavior for users if their usage is different.
Note that the syntax (and thus usage) is different by design:
$ emerge -1pv '|| ( sys-apps/openrc sys-apps/systemd )'
!!! '|| ( sys-apps/openrc sys-apps/systemd )' is not a valid
package atom.
!!! Please check ebuild(5) for full details.
The reasons for changing dependency syntax are worth it:
For the dependency syntax, having :* as a default breaks things or
causes a lot of work. If explicit slots (or :0) were the default, it
works and you spare out dealing with lots of reverse dependencies when
you introduce a new slot.
When you depend on libfoo; I think you mean to depend on the libfoo
that is currently in the Portage tree (eg. libfoo:0 or so), whereas
libfoo:* would break as soon as the libfoo maintainer starts a new slot.
With libfoo:*, this then results in the following procedure:
1. Add libfoo:2 to the Portage tree and package.mask.
2. Inform everyone to update the dependency accordingly, wait for it.
3. Unmask libfoo:2. (Somewhere in the future)
Whereas with an implicit or explicit libfoo:${SLOT}, this results in:
1. Add libfoo:2 to the Portage tree. (Right now, without mask)
2. Maintainers support libfoo:2 over time as they bump packages.
As the former is frustrating, it can have library maintainers create a
new package instead of a new SLOT or not add the new version at all;
whereas the latter would allow the library maintainer to just add it,
especially as it is the task of individual maintainers to test their
package against new libraries as they come along.
Thus, that's why I'd like to see slot-less dependencies go and make it
policy or at least a repoman QA warning that people specify them.
Specifying it without a slot is moving the work of dependency testing
on the library maintainer instead of the package maintainer, causing the
library maintainer to either test tons of packages or file tons of bug.
Why have the library maintainer do extra work when a package maintainer
can just test it instead during a version bump? (As required anyway)
What do you think? Why do you think we should still keep a default :*?
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
