Re: [gentoo-dev] The fallacies of GLEP55
On Friday 15 May 2009 02:42:33 George Prowse wrote: Having countered those four points I guess you agree with the other five then. Over 50% success rate (by your definition) is hardly being ignorant or trolling In that case we can assume that Patrick agrees with all my counterpoints, since he hasn't responded to my email at all.
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Richard Freeman ri...@gentoo.org said: AllenJB wrote: All that's going to happen is Gentoo will have many many buggy and out of date packages in the MAIN TREE. Exactly where they shouldn't be. You claim quality won't be sacrificed, but I simply can't see this without any attempt to solve the manpower issues first. Isn't the purpose of this project already somewhat covered by Sunrise? I have to agree with your points. We need to have quality standards for packages. Currently we have a couple of tiers: 1. Main tree - every ebuild has an official maintainer and gets prompt security updates/etc. New features might get a little more stale, but you aren't going to be running at risk if you only use the main tree and routinely emerge -u world. If a package falls behind on security it gets masked and booted. 2. Overlays - you're on your own and at the general mercy of the overlay maintainer. 3. Sunrise (just a special case of an overlay) - somewhere in-between. Again, you have to opt-in. AFAIK, we have never explicitly made this distinction clear. if we had, we would have to remove stuff from portage which doesnt live up to the standards. it is also not true from a more real world perspective: there are many packages in portage that have a standard which is much lower than what is in some overlays. and there are many packages in overlays which live up to a quality standard way above portage's average. if you want to exaggerate a bit, we have roughly 500 ebuilds in portage which are maintainer-needed and have only a few users and thats why you want to keep popular packages out of the tree? its weird, how this whole thing started with wanting to accomodate our users better and then other people come around and argue against it in order to protect our users... user who want protection run stable arch! given the current state of the tree, its hypocritical to be against this proposal, IMHO. however, one could try to implement the above quality standards, possibly by splitting up the tree. this issue, as well as some others very similar to this one, have come up many times before. I suggest we do something about it... (splitting the tree or moving more stuff wholesale into portage and have a better rating system... whatever) Fedora is a much more current distribution than Gentoo - and has been for a couple of years... regards Thilo I think that we still need to have defined levels of quality, so if we start putting unmaintained stuff in the main tree then we absolutely need to preserve a mechanism for users to indicate what level of quality they desire. Users running a typical install shouldn't inadvertently have dependencies pulled in which aren't fully controlled for security issues. Could something like sunrise be integrated into the main tree? Sure. However, there would need to be lots of rules and QA checks like non-sunrise packages not depending on sunrise packages and the sunrise packages are somehow clearly marked. Maybe even an ACCEPT_QUALITY = good-luck-with-that setting or something like that in make.conf. We might also need tiered levels of security in cvs. I'm not convinced that in the end it will be any better than just having those who are interested add an overlay to their tree. Maybe a better option would be a way to make overlays more seamless. Additionally we could have rating categories for overlays like security responsiveness, currency with upstream, etc. The gentoo project would ask overlays to declare their policies as a condition of being accessible via the seamless interface, and would drop overlays if they don't follow their policies. It would still be easy for users to pick non-standard overlays but it would be clear that they are venturing off on their own if they do this (just as is the case with layman today). Sure, I'd love to see an extra 1000 supported packages in portage, but the key is supported, not just shoveled-in. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thilo Bangert wrote:
Richard Freeman ri...@gentoo.org said:
AllenJB wrote:
All that's going to happen is Gentoo will have many many buggy and
out of date packages in the MAIN TREE. Exactly where they shouldn't
be. You claim quality won't be sacrificed, but I simply can't see
this without any attempt to solve the manpower issues first.
Isn't the purpose of this project already somewhat covered by
Sunrise?
I have to agree with your points. We need to have quality standards
for packages. Currently we have a couple of tiers:
1. Main tree - every ebuild has an official maintainer and gets prompt
security updates/etc. New features might get a little more stale, but
you aren't going to be running at risk if you only use the main tree
and routinely emerge -u world. If a package falls behind on security
it gets masked and booted.
2. Overlays - you're on your own and at the general mercy of the
overlay maintainer.
3. Sunrise (just a special case of an overlay) - somewhere in-between.
Again, you have to opt-in.
AFAIK, we have never explicitly made this distinction clear. if we had, we
would have to remove stuff from portage which doesnt live up to the
standards.
We should try to work with the maintainers of those packages to improve things.
it is also not true from a more real world perspective: there are many
packages in portage that have a standard which is much lower than what is
in some overlays. and there are many packages in overlays which live up to
a quality standard way above portage's average.
This is probably true, but without knowing which is which we can't do much about
it. Even if we did know, that still doesn't mean packages could be moved from
overlays to main tree, as they would instantly become unmaintained.
if you want to exaggerate a bit, we have roughly 500 ebuilds in portage
which are maintainer-needed and have only a few users and thats why you
want to keep popular packages out of the tree?
If packages are popular enough someone will care enough to add and maintain
them.
its weird, how this whole thing started with wanting to accomodate our
users better and then other people come around and argue against it in
order to protect our users...
user who want protection run stable arch!
Perhaps there are pros and cons to actually doing this, like with most things.
It seems like some are arguing that the value of having more ebuilds outweighs
the bad of having more less-maintained ebuilds. Others may feel differently.
given the current state of the tree, its hypocritical to be against this
proposal, IMHO.
See above.
however, one could try to implement the above quality standards, possibly
by splitting up the tree.
Overlays are effectively a splitting of the tree, so we are already there.
this issue, as well as some others very similar to this one, have come up
many times before. I suggest we do something about it... (splitting the
tree or moving more stuff wholesale into portage and have a better rating
system... whatever)
Fedora is a much more current distribution than Gentoo - and has been for
a couple of years...
Please elaborate what exactly you think Fedora does better than we do. I have no
first-hand experience with Fedora, but from what I read I had the impression
that sometimes they go with new stuff before it is ready, like KDE4 and
pulseaudio.
I like about the current situation that we also have all those things available
AFAICS, but have very broad choices in how much we want to bleed.
IMO this is a different issue than having supposedly popular ebuilds not in main
tree.
I think there is a steady inflow of fresh developers from sunrise (and other
places). Does anyone have a chart? I'd also like to know from prospective
developers if they have trouble getting recruited, through sunrise or other
projects.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoNPjsACgkQp/VmCx0OL2x/lgCgrvL/3f0XqLJPEe6+BOCl/0R8
j3kAn1jLAW1flDAZt7wu9IuSMO3jtmZe
=szxf
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Thilo Bangert wrote: AFAIK, we have never explicitly made this distinction clear. if we had, we would have to remove stuff from portage which doesnt live up to the standards. I'm all for that. In reality we tend to leave them alone until a security issue actually comes up, which is probably a reasonable compromise (since it also takes work to remove them). In any case, failure to completely meet a standard does not automatically imply that the standard is worthless. it is also not true from a more real world perspective: there are many packages in portage that have a standard which is much lower than what is in some overlays. and there are many packages in overlays which live up to a quality standard way above portage's average. I don't think anybody has issues with overlays that choose to have higher quality standards than portage. I'm all for that. I'm concerned with the quality level in portage - since that is what we attach our name to. If some other repository wants to do a better job than more power to them! However, Gentoo cannot endorse all overlays as being official repositories, because clearly there is no standard for quality when all it takes to have an overlay is to set up an rsync or http server and put some ebuilds on it. if you want to exaggerate a bit, we have roughly 500 ebuilds in portage which are maintainer-needed and have only a few users and thats why you want to keep popular packages out of the tree? Actually, where any of those ebuilds cause problems I'm fine with getting rid of them. I'm certainly not arguing for inconsistency. I'm just suggesting that we shouldn't make the problem worse. If a package is popular then somebody should volunteer to maintain it (whether by becoming a gentoo dev or by starting their own overlay). If that isn't happening than clearly the package isn't THAT important. This is open source - if you have an itch, then scratch it! Don't just complain that nobody else is scratching YOUR itch (even if it is a popular itch). In any case, my opinion is that for packages to be in portage they should be of a certain level of quality, and a developer should be accountable for the packages they commit. Anybody is welcome to grab ebuilds out of CVS, screen them, and commit them. However, if they cause havoc then the developer can't just say but it was popular and unmaintained, so I figured I'd just commit something without looking at it. If a developer is willing to commit an appropriate amount of time to QA then they essentially have become a maintainer and the package is no-longer maintainer-wanted.
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009/5/15 Marijn Schouten (hkBst) hk...@gentoo.org: Thilo Bangert wrote: Fedora is a much more current distribution than Gentoo - and has been for a couple of years... Please elaborate what exactly you think Fedora does better than we do. I have no first-hand experience with Fedora, but from what I read I had the impression that sometimes they go with new stuff before it is ready, like KDE4 and pulseaudio. I like about the current situation that we also have all those things available AFAICS, but have very broad choices in how much we want to bleed. IMO this is a different issue than having supposedly popular ebuilds not in main tree. AFAIK Fedora (formerly Red Hat Linux) is the playground for Red Hat Enterprise Linux like Opensuse is for Suse Linux Enterprise. So it makes more sense to compare it with the Gentoo unstable tree instead of the stable one. Assuming this there is probably not a big difference in the up-to-dateness. -- Daniel Pielmeier
Re: [gentoo-dev] The fallacies of GLEP55
Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. This seems to come up from time to time but I don't see how this is a problem that GLEP 55 solves. If the rule is first line of the ebuild starting with EAPI= and the ebuild is as you suggest above, then the EAPI is 4 (without any regard whatsoever to what might be in foo). The counterargument seems to be that eclasses should be able to modify EAPI behavior. However, if you want to do this then you DEFINITELY don't want to put the EAPI in the filename - unless you want eclasses to start renaming the ebuilds to change their EAPIs and then trigger a metadata regen. This seems to be a case where a problem is proposed, with a solution. Somebody proposes an alternate solution and the complaint is raised that it doesn't handle situation X. However, the original proposed solution doesn't handle situation X either, so that can hardly be grounds for accepting it over the alternate. I'm actually more in favor of an approach like putting the EAPI in a comment line or some other place that is more out-of-band. Almost all modern file formats incorporate a version number into a fixed position in the file header so that it is trivial for a program to figure out whether or not it knows how to handle the file. Another common approach is to put a header-length field and add extensions to the end of a header, so that as long as you don't break past behavior you could create a file that is readable by older program versions (perhaps with the loss of some metadata that the older version doesn't understand). Just look up the UStar tar file format or the gzip file format for examples. Of course, such file formats generally aren't designed to be human-readable or created with a text editor. The same applies to executables. It is impossible from the filename to tell if /bin/bash is in a.out or ELF format, or if it is a shell script. Instead a simple standard is defined that allows the OS to figure it out and handle it appropriately. If you try to run an ELF on some ancient version of linux it doesn't crash or perform erratic behavior - it will simply tell you that it doesn't understand the file format (invalid magic number). In any case, I'm going to try to restrain myself from replying further in this thread unless something genuinely new comes up. When I see 26 new messages in my gentoo-dev folder I should know by now that somebody has managed to bring up GLEP 55 again... :)
Re: [gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed
On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano Müller wrote: Thanks Robin for finally pushing this in the tree, just didn't find the time to. Maybe it's a good time to emphasize this: Keep in mind that changing the EAPI in an ebuild requires a revision bump (including reset to unstable keywords, etc.). That's going to cause a large problem. The entire point is that the STABLE ebuilds need to be changed, otherwise they will try to depend on the libusb-1 series (and fail dismally). For switching from EAPI0 to EAPI1, if the ebuild still compiles fine, then I see no reason that a slot dep change cannot be just put in with the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further changes are needed for that case). -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpVApNLnp2FS.pgp Description: PGP signature
Re: [gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed
Thanks Robin for finally pushing this in the tree, just didn't find the time to. Maybe it's a good time to emphasize this: Keep in mind that changing the EAPI in an ebuild requires a revision bump (including reset to unstable keywords, etc.). Cheers, Tiziano Am Donnerstag, den 14.05.2009, 17:06 -0700 schrieb Robin H. Johnson: libusb-1 is in the tree now. This means that you get to go and test all your apps that use it. There's a list further down of all packages and all ebuilds. Every one of these needs to be tested, and amended in one of two ways: - Does work with libusb-compat: 1. Change your [R]DEPEND to virtual/libusb:0 - Does not work with libusb-compat, or you don't have time to fully test right now: 1. Change your [R]DEPEND to dev-libs/libusb:0 (preserve any existing version dependency as well). 2. If it really doesn't work, leave a comment in the ebuild as well as on this thread. Both of these changes require that you move up from EAPI0 to at least EAPI1, where slot dependencies are supported. As part of the migration strategy, I'm going to be going through all of the ebuilds listed here, and just changing them to include the slot dependancy directly on dev-libs/libusb:0 initially, and including a notation that libusb-compat is untested. For the inevitable question, as to why we need to do this, while 99.9% of libusb-applications will be fine, there were specific bad practices that were previously done with libusb-0 that DO break under libusb-compat. They are described in detail in the libusb-compat README. List of packages: = app-accessibility/brltty app-accessibility/gok app-crypt/asedriveiiie-serial app-crypt/asedriveiiie-usb app-crypt/asekey app-crypt/ccid app-crypt/gnupg app-misc/acdctl app-misc/digitemp app-misc/g15daemon app-misc/ifp-line app-misc/lcd4linux app-misc/lcdproc app-misc/lirc app-misc/logitech-applet app-misc/razertool app-misc/rioutil app-mobilephone/bitpim app-mobilephone/gammu app-mobilephone/gnokii app-mobilephone/moto4lin app-mobilephone/obex-data-server app-mobilephone/openmoko-dfu-util app-pda/barry app-pda/coldsync app-pda/pilot-link app-text/calibre dev-embedded/avrdude dev-embedded/ftdi_eeprom dev-embedded/libftdi dev-embedded/openocd dev-embedded/pk2cmd dev-libs/cyberjack dev-libs/libg15 dev-libs/libhid dev-libs/luise-bin dev-libs/openct-.ebuild dev-libs/openct dev-libs/openobex dev-libs/serdisplib dev-util/usb-robot kde-base/kcontrol kde-base/kdebase kde-base/systemsettings media-gfx/gphoto2 media-gfx/iscan media-gfx/sane-backends media-libs/hamlib media-libs/libdjconsole media-libs/libgphoto2 media-libs/libifp media-libs/libkarma media-libs/libmtp media-libs/libnjb media-libs/libptp2 media-sound/ardour media-tv/linuxtv-dvb-apps media-video/isight-firmware-tools net-dialup/umtsmon net-misc/dahdi-tools net-misc/zaptel net-print/hplip net-print/mtink net-wireless/bluez net-wireless/bluez-utils net-wireless/wispy-tools sci-geosciences/gpsbabel sci-geosciences/qlandkartegt-garmindev sci-geosciences/qlandkarte sci-libs/indilib sci-libs/libticables2 sys-apps/hal sys-apps/ifd-gempc sys-apps/lomoco sys-apps/pcsc-lite sys-apps/usb_modeswitch sys-apps/usbutils sys-auth/thinkfinger sys-fs/owfs sys-libs/libchipcard sys-power/nut sys-power/sispmctl x11-misc/ifpgui xfce-extra/xfce4-cellmodem List of all ebuilds: app-accessibility/brltty/brltty-3.10.ebuild app-accessibility/gok/gok-2.24.0.ebuild app-accessibility/gok/gok-2.26.0.ebuild app-crypt/asedriveiiie-serial/asedriveiiie-serial-3.4.ebuild app-crypt/asedriveiiie-serial/asedriveiiie-serial-3.5.ebuild app-crypt/asedriveiiie-usb/asedriveiiie-usb-3.4.ebuild app-crypt/asedriveiiie-usb/asedriveiiie-usb-3.5.ebuild app-crypt/asekey/asekey-3.3.ebuild app-crypt/asekey/asekey-3.4.ebuild app-crypt/ccid/ccid-1.3.0.ebuild app-crypt/ccid/ccid-1.3.10.ebuild app-crypt/ccid/ccid-1.3.1.ebuild app-crypt/ccid/ccid-1.3.5.ebuild app-crypt/ccid/ccid-1.3.8.ebuild app-crypt/gnupg/gnupg-1.4.9.ebuild app-misc/acdctl/acdctl-1.1.ebuild app-misc/digitemp/digitemp-3.3.2.ebuild app-misc/digitemp/digitemp-3.5.0.ebuild app-misc/g15daemon/g15daemon-1.2.7-r1.ebuild app-misc/g15daemon/g15daemon-1.9.5.3-r2.ebuild app-misc/ifp-line/ifp-line-0.2.4.5.ebuild app-misc/ifp-line/ifp-line-0.3.ebuild app-misc/lcd4linux/lcd4linux-0.10.0-r1.ebuild app-misc/lcd4linux/lcd4linux-0.10.1_rc2-r1.ebuild app-misc/lcd4linux/lcd4linux-0.10.1_rc2-r2.ebuild app-misc/lcdproc/lcdproc-0.5.1-r4.ebuild app-misc/lcdproc/lcdproc-0.5.2-r1.ebuild app-misc/lcdproc/lcdproc-0.5.2-r2.ebuild app-misc/lirc/lirc-0.8.3_pre1.ebuild app-misc/lirc/lirc-0.8.3-r2.ebuild app-misc/lirc/lirc-0.8.4a.ebuild app-misc/lirc/lirc-0.8.4.ebuild app-misc/logitech-applet/logitech-applet-0.4_pre1-r2.ebuild app-misc/razertool/razertool-0.0.7.ebuild app-misc/rioutil/rioutil-1.5.0-r1.ebuild
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote:
This .uselect
should not contain symlinks, but plain (text?) files only.
Do we really need more than one file?
No, at least not to define the _values_ of a profile.
Checklist:
* Hostname
* Uname
* {$chost}
Mmm... Maybe we can simplify this with a parameter like:
# eval something
eval hostname superhost
what
to
do
# end something
Then if command hostname outputs superhost we know what-to-do.
Eventually, we should pass something like -Dhostname=superhost as
cmdline parameter to uselect...
This way it would get ultra versatile.
What if there is some hierarchy in .uselect/ much like the profiles in
gentoo-x86 tree, using some kind of 'parent' files to inherit/override
settings for this one project, where 'parent' can contain something like
$(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)?
Would this really be necessary? We can define hierarchy into a
single .uselect file. Even the use of folders (folder .uselect/) isn't
necessary. I think a single file can handle all this...
Eventually yes.
Lets see an
example:
# profile something
I don't like to have anything interpreted after the usual and well-known
comment-marker, this just feels hackish.
do this 3 - override the overridden =)
The actions to be done like do this 3 are a simple call to uselect
using module do and action this with 3 as parameters.
fine.
I do have something like this content-syntax in mind for .uselect (or
eventually some .uprofile) file:
888
version 0.1
include path/to/another/uselect/file
profile generic solaris {
module A actionAX valueAX1 valueAX2
module B actionBX valueBX1 valueBX2
}
profile generic host {
module C actionCX valueCX1
}
profile superhost {
inherit profile generic solaris
inherit profile generic host
module C actionCX newvalueCX1
module A actionAX newvalueAX1 newvalueAX2
module D actionDY valueBY1 valueBY2
}
profile generic user {
module E actionEX valueEX1
}
profile user haubi {
inherit profile generic user
module F actionFX valueFX1
}
profile any user on superhost {
module G actionGX valueGX1
}
profile fallback host {
inherit profile generic host
module A actionAX valueAX1 valueAX2
}
activation superhost activation {
in category host
on fallback level 0
when $hostname matches string superhost
activate profile superhost
}
activation haubi on superhost {
in category user
on fallback level 0
when $username matches string haubi
when $hostname matches string superhost
activate profile any user on superhost
activate profile user haubi
}
activation haubi {
in category user
on fallback level 1
when $username matches string haubi
activate profile user haubi
}
activation gentoo host {
in category host
on fallback level 1
when $hostname matches regex .*\.gentoo\.org
activate profile fallback host
}
888
I'm not sure to have an ascending fallback level or descending
priority value, but both should allow for negative integer values.
The selection of one or more profiles is controlled by activation
entries, independent for each category. The order and selection of
categories is done via a commandline argument, fex --categories.
Profiles are selected when all of the when entries (besides category
and fallback level) in activation {} do match.
Selected are *all* of the matching profiles in the *lowest* fallback
level *only*, which does have at least one matching profile.
And I'm thinking of something like this commandline:
$ uselect \
--categories host,user \
--define hostname=`hostname` \
--define username=`whoami`
Remember that profile creation/storing/managing should be automatic and
nothing would need to be written by hand.
Yes, would be fine. When using something like above configuration file
syntax, some GUIding tool would be useful, at least to see which
profiles are selected for specific cmdline args.
By other words, create a basic
profile automatically using your currently running settings and then
alter the profile with the util to add constrains to it.
Sounds interesting...
Remember that
all the machines that this profile is read would need to have the same
uselect modules into it's /usr/share/uselect/modules or similar.
Indeed, yes.
Ha! This kind of inheritance tree could be a solution for my long
standing bug here to simplify our way too complex environment script...
This is a basic idea from softenv so it has has it's place into uselect.
Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/
Do you mean this one?
The question now is, bloat it all into uselect or create a uprofile
util? I like the idea of having to use only uselect for basic profiling
and using uprofile for further managing.
That's indeed the question.
Mmmm... As you wrote I realized: Complain if module versions are
different is not a bad idea at all...
Indeed, not only the configuration needs to be
[gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
Daniel Pielmeier daniel.pielme...@googlemail.com posted 6142e6140905150344y4a8007b5wd352ffe891e49...@mail.gmail.com, excerpted below, on Fri, 15 May 2009 12:44:47 +0200: 2009/5/15 Marijn Schouten (hkBst) hk...@gentoo.org: Thilo Bangert wrote: Fedora is a much more current distribution than Gentoo - and has been for a couple of years... Please elaborate what exactly you think Fedora does better than we do. I have no first-hand experience with Fedora, but from what I read I had the impression that sometimes they go with new stuff before it is ready, like KDE4 and pulseaudio. I like about the current situation that we also have all those things available AFAICS, but have very broad choices in how much we want to bleed. IMO this is a different issue than having supposedly popular ebuilds not in main tree. AFAIK Fedora is [Red Hat's unstable.] So it makes more sense to compare it with the Gentoo unstable tree instead of the stable one. Assuming this there is probably not a big difference in the up-to-dateness. Well, yes and no. As the GP said, they sometimes go with new stuff before it's ready -- before Gentoo even has it in-tree hard-masked let alone ~arch, while it's still in the various project overlays. I know they've had some serious issues with xorg on Intel GPUs at least, due to running versions that aren't in our tree yet, only in the X overlay, because Fedora is running clearly not even ~arch-ready packages, sometimes even xorg prereleases. Years ago we'd have put these in-tree but hard-masked for those who wanted to try them. Now, depending on the package and Gentoo but more likely as the complexity rises to meta-package levels, those who want to try them must load an overlay. As someone who selectively unmasks and tries these, having them in-tree but hard-masked is convenient, but I understand why projects may prefer overlays in many cases. However, none of this directly applies to the subject at hand, because while we're talking new versions of packages already in-tree here, the subject at hand is packages that aren't in-tree in any form yet. -- 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
[gentoo-dev] Re: Files owned by multiple slots
Sven sv...@delirium.ch posted loom.20090514t182756-...@post.gmane.org, excerpted below, on Thu, 14 May 2009 18:34:29 +: Duncan 1i5t5.duncan at cox.net writes: FWIW, that'd not be a portage issue per se, but an EAPI issue, since it I see, very interesting! Sounds like a lengthy process, but never mind. Do you know where EAPI changes are discussed? (Google and the Bugtracker didn't yield a useful reply.) Here? (See the current GLEP55 thread, among others.) Also the council list and meetings, since they must approve EAPIs before they are allowed in the tree. Also see the various PMS (package management spec) threads, and the app-doc/pms package, for the current EAPI documentation. From the package metadata, the homepage is: http://www.gentoo.org/proj/en/qa/pms.xml -- 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
[gentoo-dev] EAPI Changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote: On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote: Thanks Robin for finally pushing this in the tree, just didn't find the time to. Maybe it's a good time to emphasize this: Keep in mind that changing the EAPI in an ebuild requires a revision bump (including reset to unstable keywords, etc.). That's going to cause a large problem. The entire point is that the STABLE ebuilds need to be changed, otherwise they will try to depend on the libusb-1 series (and fail dismally). For switching from EAPI0 to EAPI1, if the ebuild still compiles fine, then I see no reason that a slot dep change cannot be just put in with the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further changes are needed for that case). As far as I know, the only time you need to do a rev bump and reset to unstable is if you change the files that are installed by the package. So, as far as I know, unless you are migrating to an EAPI that is not stable or changing the files that are installed by the package, it is not necessary to do a rev bump just for changing the EAPI as long as you make sure that the ebuild emerges fine under the new EAPI. - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoNgNcACgkQblQW9DDEZTgorACdGfiXec4JUIC3UJDL/sGctbEi FpwAn3UxUOjxuQUxl0w5S95M271+306Q =jinO -END PGP SIGNATURE-
[gentoo-dev] Last rites: Ruby 1.8 with Oniguruma patches, ruby-config
# Alex Legler a...@gentoo.org (15 May 2009) # Masked for removal wrt bug #251833. Due for removal in 30 days. # Use app-admin/eselect-ruby instead. dev-ruby/ruby-config =dev-lang/ruby-1.8.6_p114 Ruby _p114 is the last Ruby with Oniguruma patches, however there are numerous security issues. Ruby 1.9.1 will contain Oniguruma again, people needing it in 1.8 can use a gem [1]. ruby-config is superseded by eselect-ruby. Cheers, Alex [1] http://oniguruma.rubyforge.org/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-texlive/texlive-langmanju
# Merged in dev-texlive/texlive-langmongolian-2008, use that instead # Masked for removal on 15 June 2009 dev-texlive/texlive-langmanju Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Friday 15 May 2009 05:44:47 Richard Freeman wrote: Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. This seems to come up from time to time but I don't see how this is a problem that GLEP 55 solves. If the rule is first line of the ebuild starting with EAPI= and the ebuild is as you suggest above, then the EAPI is 4 (without any regard whatsoever to what might be in foo). The counterargument seems to be that eclasses should be able to modify EAPI behavior. However, if you want to do this then you DEFINITELY don't want to put the EAPI in the filename - unless you want eclasses to start renaming the ebuilds to change their EAPIs and then trigger a metadata regen. This seems to be a case where a problem is proposed, with a solution. Somebody proposes an alternate solution and the complaint is raised that it doesn't handle situation X. However, the original proposed solution doesn't handle situation X either, so that can hardly be grounds for accepting it over the alternate. I'm actually more in favor of an approach like putting the EAPI in a comment line or some other place that is more out-of-band. Almost all modern file formats incorporate a version number into a fixed position in the file header so that it is trivial for a program to figure out whether or not it knows how to handle the file. Another common approach is to put a header-length field and add extensions to the end of a header, so that as long as you don't break past behavior you could create a file that is readable by older program versions (perhaps with the loss of some metadata that the older version doesn't understand). Just look up the UStar tar file format or the gzip file format for examples. Of course, such file formats generally aren't designed to be human-readable or created with a text editor. The same applies to executables. It is impossible from the filename to tell if /bin/bash is in a.out or ELF format, or if it is a shell script. Instead a simple standard is defined that allows the OS to figure it out and handle it appropriately. If you try to run an ELF on some ancient version of linux it doesn't crash or perform erratic behavior - it will simply tell you that it doesn't understand the file format (invalid magic number). In any case, I'm going to try to restrain myself from replying further in this thread unless something genuinely new comes up. When I see 26 new messages in my gentoo-dev folder I should know by now that somebody has managed to bring up GLEP 55 again... :) If I understand the problem GLEP 55 is trying to solve correctly, it stems from portage's assumption that an unknown EAPI is equal to EAPI 0. Could that assumption be changed to an unknown EAPI is equal to the latest supported EAPI. Now I understand that this change would have to wait until all the ebuilds in the portage tree correctly define their EAPI, but would the idea be technically feasible at least excluding EAPI0 ebuilds? I think it would be if all EAPIs are forward compatible up until the EAPI declaration in the ebuild.
Re: [gentoo-dev] The fallacies of GLEP55
On Fri, 15 May 2009 11:16:11 -0500 Robert R. Russell nahoy_kb...@hushmail.com wrote: If I understand the problem GLEP 55 is trying to solve correctly, it stems from portage's assumption that an unknown EAPI is equal to EAPI 0. Could that assumption be changed to an unknown EAPI is equal to the latest supported EAPI. Now I understand that this change would have to wait until all the ebuilds in the portage tree correctly define their EAPI, but would the idea be technically feasible at least excluding EAPI0 ebuilds? I think it would be if all EAPIs are forward compatible up until the EAPI declaration in the ebuild. No, that still wouldn't help, because the package manager doesn't know that what it thinks is the 'latest' EAPI (not that there really is such a thing -- EAPIs aren't a linear sequence) actually is the 'latest' EAPI. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote: [...] So if you were a lazy Unix coder you'd just restrict the current rules a bit so that there's only one line starting with EAPI= allowed (or maybe you just take the first or last one, but that's annoying) and if no such line matches you can safely assume EAPI0 Maybe you're very lazy, so you explicitly forbid eclasses from setting or changing EAPI. That also avoids weird effects that make you lose lots of time for debugging because you didn't think about what would happen if foo.eclass set EAPI=3.14 and bar.eclass inherited later set EAPI=1 ... And magically you haven't really changed current behaviour, can get the EAPI without sourcing it and you can be lazy once more. Isn't it great? As I've stated a long time ago, I'm for this solution. My understanding is that there are 2 objections to this: 1) We can't change the ebuild format to XML or what have you. I think this is a problem to deal with *if it ever happens*. I am completely against trying to solve a problem that will not exist in the foreseeable future. 2) There might be a performance impact for cases where the metadata is uncached - I think the impact is acceptable in the face of the fugliness added by putting the EAPI in the ebuild's name (Joe Peterson summarise this quite well earlier [1]). Really, the key issue seems to be (1), because there's no other good reason to be trying to adopt this GLEP. -- Arun [1] http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg29311.html signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The fallacies of GLEP55
On Sat, 16 May 2009 00:28:36 +0530 Arun Raghavan ford_pref...@gentoo.org wrote: As I've stated a long time ago, I'm for this solution. My understanding is that there are 2 objections to this: 3) It doesn't solve the problem. It doesn't allow things like version format extensions. That's the big one, not the other two. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: The fallacies of GLEP55
Robert R. Russell wrote: snip If I understand the problem GLEP 55 is trying to solve correctly, it stems from portage's assumption that an unknown EAPI is equal to EAPI 0. No, portage will reject an ebuild with an unknown EAPI, as per the spec. (This is important for shared overlays.) Search for: def eapi_is_supported ..in pym/portage/__init__.py for the impl, and you can see usage of it in pym/_emerge/__init__.py, if you want to confirm this (or are just interested in the code;) http://sources.gentoo.org/viewcvs.py/portage/main/trunk/ (has instructions for anonymous download, should anyone be interested in following portage development, or perhaps contributing at some stage.) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: The fallacies of GLEP55
On Fri, 15 May 2009 20:12:03 +0100 Steven J Long sl...@rathaus.eclipse.co.uk wrote: Robert R. Russell wrote: snip If I understand the problem GLEP 55 is trying to solve correctly, it stems from portage's assumption that an unknown EAPI is equal to EAPI 0. No, portage will reject an ebuild with an unknown EAPI, as per the spec. You're confusing the term 'unknown' here. Before an ebuild has had its metadata generated, its EAPI is unknown. At this point, the package manager assumes EAPI 0. After an ebuild has had its metadata generated, its EAPI is either known or unsupported, but if known may be unspecified. If it is known but unspecified, the package manager treats it as equivalent to EAPI 0. Conceptually, these aren't the same thing. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: The fallacies of GLEP55
Robert Bridge wrote: Patrick Lauer wrote: On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. Interesting, but quite subtly wrong. I'm surprised that you try to slip such an obvious logical mistake in in an attempt to save your arguments. Patrick, in the interest of making this comprehensible to the average schmuck like me, which you seem to be trying to do, could you actually explain WHY this is wrong? Otherwise it looks like you are simply trying the arrogant I am right because I say so line. AFAIK, setting EAPI has to be done before any call to inherit. Not to do so is considered a QA violation, and I believe repoman will scream at you if you do so (I could be wrong as I don't use it. If it doesn't, perhaps it should.) Furthermore, eclasses are not supposed to set EAPI. They can test what the ebuild's EAPI is, and act accordingly, should the need arise, but they are not supposed to set it. (I'm informed this is disallowed by GLEP-55 in any event, so it's not a restriction anyone cares too much about, one would surmise.) From conversation with Harring, who invented the whole EAPI thing, they were never meant to change very quickly. The complementary mechanism was elibs, that is files with useful library functions, which is often how eclasses are used nowadays. Eclasses in that context would be able to set EAPI, since they would effectively be a template, not a repository of functionality. (This is my no doubt flawed understanding of what he said; I'm sure he'll correct, and hopefully forgive, any errors which are of course my own.) I am curious as to why eclass versioning, which has been proposed for donkey's years, hasn't seen as much impetus as what appear from a software engineering perspective to be quite esoteric, and poorly thought-through, use-cases. There does appear to be a process issue, though resolution is another matter. Good luck with the distro. :-) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] The fallacies of GLEP55
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote: It can't, because it doesn't know the EAPI until it's sourced the thing using bash. Using things like += in global scope will break older bash versions to the point that they can't reliably extract EAPI. I just figured out a line in bash that will get an EAPI without sourcing the ebuild: eval `grep '^EAPI=' ebuildfile | head -n 1` will set EAPI in the current scope to EAPI in the ebuild, without sourcing it, unless the issue with something like this would be its use of grep and head, but these are both in the system set, so unless you don't want to depend on the system set, I don't know what the objection would be. - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoNxeEACgkQblQW9DDEZThaFACfYSQTpPTxfh3MzvErzbSNGZ8M 46AAoIyGTJxbWQ4Be7075uHXYN+hfnDl =X3Wn -END PGP SIGNATURE-
Re: [gentoo-dev] The fallacies of GLEP55
On Fri, 15 May 2009 14:43:29 -0500 William Hubbs willi...@gentoo.org wrote: On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote: It can't, because it doesn't know the EAPI until it's sourced the thing using bash. Using things like += in global scope will break older bash versions to the point that they can't reliably extract EAPI. I just figured out a line in bash that will get an EAPI without sourcing the ebuild: eval `grep '^EAPI=' ebuildfile | head -n 1` will set EAPI in the current scope to EAPI in the ebuild, without sourcing it, unless the issue with something like this would be its use of grep and head, but these are both in the system set, so unless you don't want to depend on the system set, I don't know what the objection would be. The objection is that your code doesn't work. It's entirely legal to do, say: export EAPI=1 or: inherit versionator if version_is_at_least 2 ; then EAPI=2 else EAPI=0 fi Besides, if we were able to do what your code does, we'd just code it natively, not use external programs. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Re: The fallacies of GLEP55
Ciaran McCreesh wrote: Steven J Long wrote: Robert R. Russell wrote: snip If I understand the problem GLEP 55 is trying to solve correctly, it stems from portage's assumption that an unknown EAPI is equal to EAPI 0. No, portage will reject an ebuild with an unknown EAPI, as per the spec. You're confusing the term 'unknown' here. Before an ebuild has had its metadata generated, its EAPI is unknown. At this point, the package manager assumes EAPI 0. With the format restriction, that everyone last year seemed happy with, apart from the few pushing GLEP-55, this isn't an issue. The mangler *should* be scanning first for the EAPI to see if it can even handle the rest of the ebuild (assuming it's not from the main tree or an upstream overlay, or we're not a normal user. Developer machines rightly need to do a bit more work, but it's not exactly onerous since portage automatically does it for you.) After an ebuild has had its metadata generated, its EAPI is either known or unsupported, but if known may be unspecified. If it is known but unspecified, the package manager treats it as equivalent to EAPI 0. Yes, empty = 0 as well-understood. Conceptually, these aren't the same thing. In practical terms, this is a useless proposal. It rightly got trashed last year. Let's just use a prefix instead of a suffix to indicate vcs, keep branch and upstream for dep specification, not filename, to allow inter-repo dependency for overlays for the few cases where it's actually needed, and add debian-style epochs to guarantee future expansion. If you have a use-case that actually requires more in a version specifier for upstream software, please present it and explain how it cannot be represented with the above. In passing, I must express bewildered amusement at the idea of a format with an unlimited amount of extensions. If you really want something so radically different that it cannot be handled in the Gentoo scheme, or BASH, use ONE _other_ extension. Have a good weekend, all. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Re: The fallacies of GLEP55
On Fri, 15 May 2009 21:06:13 +0100 Steven J Long sl...@rathaus.eclipse.co.uk wrote: Before an ebuild has had its metadata generated, its EAPI is unknown. At this point, the package manager assumes EAPI 0. With the format restriction, that everyone last year seemed happy with, apart from the few pushing GLEP-55, this isn't an issue. The format restriction hasn't been agreed upon, and doesn't solve the whole problem anyway. If you have a use-case that actually requires more in a version specifier for upstream software, please present it and explain how it cannot be represented with the above. Go and look at all the ebuilds using MY_PV style hacks. Group these into necessary because upstream are being silly and we're only doing this because of some utterly arbitrary rules imposed in the early days of Gentoo. Most are in the second camp. In passing, I must express bewildered amusement at the idea of a format with an unlimited amount of extensions. Not what's being proposed. We're proposing giving each format its own file extension. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI Changes
William Hubbs wrote: On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote: On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote: Thanks Robin for finally pushing this in the tree, just didn't find the time to. Maybe it's a good time to emphasize this: Keep in mind that changing the EAPI in an ebuild requires a revision bump (including reset to unstable keywords, etc.). That's going to cause a large problem. The entire point is that the STABLE ebuilds need to be changed, otherwise they will try to depend on the libusb-1 series (and fail dismally). For switching from EAPI0 to EAPI1, if the ebuild still compiles fine, then I see no reason that a slot dep change cannot be just put in with the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further changes are needed for that case). As far as I know, the only time you need to do a rev bump and reset to unstable is if you change the files that are installed by the package. So, as far as I know, unless you are migrating to an EAPI that is not stable or changing the files that are installed by the package, it is not necessary to do a rev bump just for changing the EAPI as long as you make sure that the ebuild emerges fine under the new EAPI. Indeed there's no problem switching EAPIs as long as a stable Portage supports the EAPI you are migrating to. Portage was buggy with this when EAPI 2 was introduced but that has since been fixed. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: The fallacies of GLEP55
On Friday 15 May 2009 21:06:13 Steven J Long wrote: In practical terms, this is a useless proposal. It rightly got trashed last year. No, it did not get trashed, despite some people's attempts to make their side sound more popular than it really is. Some people like the idea, some don't, and people have put forward various arguments in both directions. If it were really as widely hated as you claim (presumably with the implication that the people who still support it are horrible and evil for even thinking about it) then it wouldn't still be under discussion.
[gentoo-dev] about gold bugs
Could I ask that people stop closing bugs against the gold linker with such classy witticisms as patches welcome. There is no patch a user can provide to make a package build with the gold linker. These bugs should be assigned to toolchain, not the maintainer of the package that gold happens to break. Testers of gold, please check to see if your issue matches one of the general issues already reported on the gold tracker [i] before filing a new bug. Please assign new bugs to toolch...@g.o. [i] http://bugs.gentoo.org/269315 -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI Changes
Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty: William Hubbs wrote: On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote: On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote: Thanks Robin for finally pushing this in the tree, just didn't find the time to. Maybe it's a good time to emphasize this: Keep in mind that changing the EAPI in an ebuild requires a revision bump (including reset to unstable keywords, etc.). That's going to cause a large problem. The entire point is that the STABLE ebuilds need to be changed, otherwise they will try to depend on the libusb-1 series (and fail dismally). For switching from EAPI0 to EAPI1, if the ebuild still compiles fine, then I see no reason that a slot dep change cannot be just put in with the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further changes are needed for that case). As far as I know, the only time you need to do a rev bump and reset to unstable is if you change the files that are installed by the package. So, as far as I know, unless you are migrating to an EAPI that is not stable or changing the files that are installed by the package, it is not necessary to do a rev bump just for changing the EAPI as long as you make sure that the ebuild emerges fine under the new EAPI. Indeed there's no problem switching EAPIs as long as a stable Portage supports the EAPI you are migrating to. Portage was buggy with this when EAPI 2 was introduced but that has since been fixed. Wrong. For example: - stuff like docompress may change the content being installed depending on the package manager - --disable-static (maybe in a later EAPI) changes content - slot-dep-operators change the rdepend of installed packages, so it changes how the package manager has to handle reverse packages on uninstall (in EAPI 3) On the other hand you also have to make sure you have a stable portage for a time long enough so mostly everyone has it installed. Otherwise you could break users systems pretty badly depending on the packages. And Arch-Teams usually do a pretty good job in catching such cases. And we also always said that a rev bump should be done on non trivial changes or non-build-fixes and changing the EAPI is technical seen mostly a non-trivial change. Do we want to document the following? (do we have already?) - When is it allowed to use an EAPI in the tree (given as offset to the release of portage supporting that eapi) - When is it allowed to use an EAPI in the stable tree (given as offset of when a portage version supporting that EAPI got stable) Cheers, Tiziano -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] about gold bugs
Le 15/05/2009 23:20, Ryan Hill a écrit : Could I ask that people stop closing bugs against the gold linker with such classy witticisms as patches welcome. Honestly, a little heads up before gold hit portage would have been nice too. I already had 2 bugs with gold-related issues even before I had realized that binutils had gained a new USE flag... I honestly thought people were testing gold from an overlay or self-made ebuilds. But point taken, gold bugs are toolchain bug :) Best of luck with gold, I'm eager to try it out! Cheers, Rémi
Re: [gentoo-dev] Re: [RFC] USE_EXPAND for qemu unified ebuild
Luca Barbato wrote: Duncan wrote: Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe? Right, anyway either one or two vars, anybody has a strong feeling towards one of them or against any of them? QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS, that's it. -USE_EXPAND=APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES +USE_EXPAND=APACHE2_MODULES APACHE2_MPMS FOO2ZJS_DEVICES MISDN_CARDS FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS DVB_CARDS LIRC_DEVICES INPUT_DEVICES LINGUAS USERLAND KERNEL ELIBC CROSSCOMPILE_OPTS ALSA_CARDS ALSA_PCM_PLUGINS LCD_DEVICES CAMERAS NETBEANS_MODULES QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS alpha - userspace emulation target armeb - userspace emulation target arm - userspace emulation target cris - userspace emulation target i386 - userspace emulation target m68k - userspace emulation target mips64el - userspace emulation target mips64 - userspace emulation target mipsel - userspace emulation target mips - userspace emulation target ppc64abi32 - userspace emulation target ppc64 - userspace emulation target ppc - userspace emulation target sh4eb - userspace emulation target sh4 - userspace emulation target sparc32plus - userspace emulation target sparc64 - userspace emulation target sparc - userspace emulation target x86_64 - userspace emulation target arm - system emulation target cris - system emulation target i386 - system emulation target m68k - system emulation target mips64el - system emulation target mips64 - system emulation target mipsel - system emulation target mips - system emulation target ppc64 - system emulation target ppc - system emulation target sh4eb - system emulation target sh4 - system emulation target sparc - system emulation target x86_64 - system emulation target ppcemb - system emulation target If anybody is against it please tell ^^ lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] EAPI Changes
Tiziano Müller wrote: Am Freitag, den 15.05.2009, 23:30 +0300 schrieb Petteri Räty: William Hubbs wrote: On Fri, May 15, 2009 at 03:49:51AM -0700, Robin H. Johnson wrote: On Fri, May 15, 2009 at 10:47:24AM +0200, Tiziano M?ller wrote: Thanks Robin for finally pushing this in the tree, just didn't find the time to. Maybe it's a good time to emphasize this: Keep in mind that changing the EAPI in an ebuild requires a revision bump (including reset to unstable keywords, etc.). That's going to cause a large problem. The entire point is that the STABLE ebuilds need to be changed, otherwise they will try to depend on the libusb-1 series (and fail dismally). For switching from EAPI0 to EAPI1, if the ebuild still compiles fine, then I see no reason that a slot dep change cannot be just put in with the EAPI change. (The same cannot be said for EAPIx - EAPI2, as further changes are needed for that case). As far as I know, the only time you need to do a rev bump and reset to unstable is if you change the files that are installed by the package. So, as far as I know, unless you are migrating to an EAPI that is not stable or changing the files that are installed by the package, it is not necessary to do a rev bump just for changing the EAPI as long as you make sure that the ebuild emerges fine under the new EAPI. Indeed there's no problem switching EAPIs as long as a stable Portage supports the EAPI you are migrating to. Portage was buggy with this when EAPI 2 was introduced but that has since been fixed. Wrong. For example: - stuff like docompress may change the content being installed depending on the package manager - --disable-static (maybe in a later EAPI) changes content - slot-dep-operators change the rdepend of installed packages, so it changes how the package manager has to handle reverse packages on uninstall (in EAPI 3) Switching EAPIs in my mind means taking care it works with new EAPIs. Why switch in the first place if you aren't making modifications to the ebuild? On the other hand you also have to make sure you have a stable portage for a time long enough so mostly everyone has it installed. Otherwise you could break users systems pretty badly depending on the packages. And Arch-Teams usually do a pretty good job in catching such cases. How would this breakage happen? The ebuild in the vdb still has the old EAPI. And we also always said that a rev bump should be done on non trivial changes or non-build-fixes and changing the EAPI is technical seen mostly a non-trivial change. Switching between EAPI 0 and 1 for example is quite trivial. In Java ebuilds we should always use slot deps because jars get installed to a SLOT dependent path. I doubt our users would want to see us revision bumping our ebuilds for that. Do we want to document the following? (do we have already?) - When is it allowed to use an EAPI in the tree (given as offset to the release of portage supporting that eapi) - When is it allowed to use an EAPI in the stable tree (given as offset of when a portage version supporting that EAPI got stable) Currently: 1. Usage of an EAPI in the tree is allowed after council gives the OK. 2. When the Portage version supporting it goes stable If you want please check devmanual and file a bug if it needs updating/new info regarding this. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI Changes
On Sat, 16 May 2009 02:31:45 +0300 Petteri Räty betelge...@gentoo.org wrote: On the other hand you also have to make sure you have a stable portage for a time long enough so mostly everyone has it installed. Otherwise you could break users systems pretty badly depending on the packages. And Arch-Teams usually do a pretty good job in catching such cases. How would this breakage happen? The ebuild in the vdb still has the old EAPI. Portage likes to use metadata from the tree version of things even if there's also a version installed. This is a major nuisance, but is unfortunately considered a feature. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI Changes
Petteri Räty betelge...@gentoo.org posted 4a0dd0ed.1070...@gentoo.org, excerpted below, on Fri, 15 May 2009 23:30:37 +0300: Indeed there's no problem switching EAPIs as long as a stable Portage supports the EAPI you are migrating to. Portage was buggy with this when EAPI 2 was introduced but that has since been fixed. The case at hand is EAPI-0 EAPI-1. I've no opinion there. However, just this last week I tracked down and provided a patch for an EAPI-0 EAPI-2 conversion related bug[1] in an existing previously working ebuild, converted without a bump. It was and remained ~arch so users should have been prepared to cope, but a bump would have been nice and it would have been a SERIOUS mistake to try to do that as stable. So I agree with the earlier opinion that while it may not matter for EAPI-0 EAPI-1, as a general policy and certainly for conversions to EAPI-2 and probably EAPI-3, a revision bump and ~arch keywording, thus forcing the package thru a new stabilizing process, should be strongly recommended at minimum -- enough that a tree change to dozens of stable ebuilds such as is being discussed simply wouldn't be possible, without assuming a bump and new stabilization process, thus, effectively requiring 60-days working minimum process time (30 no-bugs, 30 stable- keywording). [1] Bug #269691, kaffeine plain:http://bugs.gentoo.org/show_bug.cgi?id=269691 secure: https://bugs.gentoo.org/show_bug.cgi?id=269691 -- 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
[gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)
Why do we let utterly *useless* discussions eat into our precious developer time? Why is it that this thread has 500 replies, but Mart's maintainer-wanted thread has less than 10? I *do not care* if the ebuild format will not be properly extensible when the need arises. We'll cross that bridge when we get to it. I *do not care* if support for live ebuilds is perfect. The three major consumers of live ebuilds (x11, kde, and gnome) are *NOT* complaining. Why is the council spending so much time on *utterly useless* discussions? Have we eliminated all other problems facing Gentoo that we now have time for enhancements of questionable value in the near future? I would like to petition the Council to _strongly_ discourage such discussion, and not to waste it's own time on things like this. Hell, in my opinion EAPI-3 is a m00t discussion when we have entire herds and archs wasting away due to inadequate developer resources and users constantly being discouraged and turned away. Let's not blatantly ignore our REAL problems. We can no longer afford to maintain the status-quo of pedantic masturbatory discussions on the finer points of ebuild formats. We cannot AFFORD to look the other way while the distro rots away. -- ~Nirbheek Chauhan who is extremely worried by this denial-syndrome in the gentoo community.
