[gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Marius Mauch <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 10 Sep 2008 03:43:11 +0200: > Maybe the best solution is to drop the non-prefixed versions of 'world' > and 'system' completely Now that's an idea. It /would/ avoid the confusion, since the new concept would come with a new name, without the legacy meaning associated with it to confuse people. What I'd really prefer would be a "legacy" message much like what portage is currently spitting out for the output module (that I see every time I run esearch, or the old earch) if people use world, telling them to use @system and @world instead... for 2.2 at least. Do the same for system but of course @system is a direct parallel there. Then for 2.3 or whatever, remove both world and system legacies and force the @ versions. However, as I believe I said earlier in the thread, I'm quite aware I'm not the one implementing it, so whatever you go with I'll happily use, regardless of whether it's what I would have thought best, or not. -- 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
Join PTC Indonesia, Cuma Klik Iklan Langsung Dibayar dengan RUPIAH Langsung ke Bank Anda
join klik rupiah (PTC INDONESIA) asli indonesia 1 klik Rp 100, 10x= Rp 1000, 20 ref = Rp 1 dibayar per Rp 5 lewat BCA atau Mandiri. Daftarnya Gratis... semua bisa tanya-jawab di forumnya, bisa beli refferal pake rupiah juga, asyik banget deh. buruan daftar kita ramaikan PTC INDONESIA. Mau Join Klik di sini http://klikrupiah.com/register.php?r=fatriyanto http://indoptc.com/news.php?r=fatriyanto http://gedebux.info/register.php?r=fatriyanto Mau nambah penghasilan lagi klik link di bawah ini terbukti membayar http://www.clixsense.com/?2301534 http://bux.to/?r=fatriyanto signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Tue, 09 Sep 2008 16:31:08 +0300 > Petteri Räty <[EMAIL PROTECTED]> wrote: > > Jorge Manuel B. S. Vicetto kirjoitti: > > > and cardoe's earlier request to the council ml, can the council > > > members discuss this proposal and consider voting it? > > > Does anyone have any objections to this proposal? > > > > I won't approve it for use in the tree before it's written as a GLEP > > in order to avoid the fiasco with EAPI 1 (it's still not documented > > properly). I can however approve the list of items. > > What about the PMS EAPI 1 documentation do you consider 'not proper'? I was personally expecting to see some sort of section called "EAPI-1" that contains something like: "EAPI-1 consists of EAPI-0 with the following features added..." Then an explanation of each change and the appropriate syntax. I did see how EAPI-1 is integrated throughout the document, which is valuable in a different way - but it's harder to answer the question "What exactly does EAPI-1 add to EAPI-0?" Perhaps I'll try sending you a patch with something like that, if I have time, and if it would be appreciated. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2
On Wed, 10 Sep 2008 01:43:45 +0100 Steve Long <[EMAIL PROTECTED]> wrote: > Marius Mauch wrote: > > > Second for the suggestions on how to handle the transition: > > - treating 'world' and '@world' differently is a no go from my POV. > > One of the main reasons to implement them as sets was to remove > > special case code in emerge, so I'm quite opposed to adding new > > special cases instead. And I'm quite sure that such a separation > > would cause confusion, and some isues regarding (end-user) > > documentation. > > We're talking about one special case in the command-line processing, > to support the existing usage that all our users are used to. It adds > practically nothing in execution time, simply expanding to @system > @world, and means that users who don't want to know about sets, or > are not thinking in set terms at the time of using emerge, will get > the result they expect. It also means we'd indefinitely have to carry another special case around for legacy reasons (removing it later would be even more painful than doing the switch now). You know, those are the things we want to get rid off, as they really make our life harder in the long run. YOu may consider it trivial in this cse, but these things always look trivial when you're adding them, and you curse about them when you have to modify the code later on. Maybe the best solution is to drop the non-prefixed versions of 'world' and 'system' completely Marius
[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: > On Mon, 08 Sep 2008 22:40:37 +0100 > Steve Long <[EMAIL PROTECTED]> wrote: >> >> * should be treated as being very quickly installable >> >> * should be treated as having zero cost for installs >> >> >> Both of which follow from "installs nothing." Or would you disagree? > > No, they're separate properties, with different implications. > Sure I understand that there are other properties which need to be addressed, and can be in APIx, but for the classic virtual as defined, which may be extended to be considered as having the associated cost of installing its deps in pkg-selection terms, or not, the given notation suffices. > Consider, for example, a split baselayout-style package. There could be > a skeleton-filesystem-layout package that does all its work in pkg_* > functions (to avoid permission and empty directory problems that come > from installing directories via the normal methods). It would install > nothing, but should not be considered for either zero-cost property. > Well, if that package spat a load of directories onto my system I'd personally consider it as installing something, and I'd expect those directories to be listed in its contents. > Or, for the reverse: a package that merely installs a simple control > file that enables functionality in another package may well be best > considered as zero-cost for package selection. If a package depends > upon || ( big-scary/processing-package simple-little/plugin-for-foo ) > and you already have foo but not plugin-for-foo installed, the right > thing for the resolver to do would be to suggest plugin-for-foo. > Sure. > As for the quickly installable property, plugin-for-foo might not > possess it -- for example, vim plugins generally do a vim tag > regeneration upon pkg_postinst, so they're not 'quick' to install even > if all they do is provide one text file. > Great, thanks for outlining some use-cases for the split properties. If virtual turns out to need a slightly different set if and when the extended properties are brought in, that can easily be done. I don't see that there's any conflict.
[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile
Duncan wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> posted >> Having to write an ebuild just to install something in a package manager >> friendly way and be able to uninstall it cleanly later is a defect, not >> a feature. > I've always rather liked that I can tell someone in -dev-help or -chat "If you can build it from source, it's simple to make an ebuild. A lot of the time you don't even need anything more than a few bash variables." So in that sense I consider asking someone to do a little bit to be a good thing, since it gets them over the first hurdle for contributing (and gives them a Gentoo buzz.) > Impressively stated, but it still doesn't get past the simple open > accessibility bit, letting the user-sysadmin do simple real-time > modifications of how the package appears on and interacts with the > individual system. > I agree with the spirit of what you're saying. Taking the detail from your other post: > it may be optional, but that doesn't help much if all the > simple ebuilds he finds to crib from end up using the pre-knowledge > required vars, leaving him nothing simple to crib from without that > knowledge. The accessibility level will have been reduced if this > happens. Yeah, but I don't think this would become the overriding method. Even if it did, in terms of what developers, or indeed automated tools, produce, the old method would, of necessity, always be allowed, and should be documented in the "stages of an ebuild" part of a devmanual. Understanding of the classic method is _required_ to make use of the declarative one, which is just syntactic sugar for the classic econf/configure parameters. (I still think the original patch is better, ofc ;)
[gentoo-dev] Re: News item: World file handling changes in Portage-2.2
Marius Mauch wrote: > Second for the suggestions on how to handle the transition: > - treating 'world' and '@world' differently is a no go from my POV. One > of the main reasons to implement them as sets was to remove special > case code in emerge, so I'm quite opposed to adding new special cases > instead. And I'm quite sure that such a separation would cause > confusion, and some isues regarding (end-user) documentation. We're talking about one special case in the command-line processing, to support the existing usage that all our users are used to. It adds practically nothing in execution time, simply expanding to @system @world, and means that users who don't want to know about sets, or are not thinking in set terms at the time of using emerge, will get the result they expect. Also it makes it easier for users who don't want @system included in @world, eg for easy use of -e @system followed by -e @world. > Though honestly I don't think this issue is as big as some other > people make it. People might miss some updates. The same would happen > if we remove packages from @system, or people switch profiles (so > @system changes). Or you could just do as above and people wouldn't miss any updates, and you'd have less support burden from users who aren't bothered about sets, who can carry on using their systems as they always have.
[gentoo-dev] Last rites: www-apps/xrms
Hi, www-apps/xrms will be removed for security reasons in 30 days. See bug #235005 ( http://bugs.gentoo.org/show_bug.cgi?id=235005). Gunnar -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ This message was sent using IMP, the Internet Messaging Program.
Re: [gentoo-dev] EAPI-2 do* functions die
On Tue, 09 Sep 2008 20:45:52 +0400
Peter Volkov <[EMAIL PROTECTED]> wrote:
> В Пнд, 08/09/2008 в 23:34 +, Jorge Manuel B. S. Vicetto пишет:
> > So we're talking about adding the following to EAPI-2:
>
> While it's not too late. Can we make dobin, doman and other do*
> functions finally die in EAPI=2? I've reviewed discussions on -dev
> [1],[2] and bug 138792 [3] and seems that the only possible stopper is
> that implementing them as functions makes impossible to use them with
> xargs. Maybe for such rather rare case we should create new functions
> (xdo{bin,*} or whatever name is better)?
I'd suggest holding off on that one. There're at least three different
ways of implementing it, all with different implications, and it needs
proper discussion.
* Using traps looks nice on the surface, but in practice they're
sufficiently weird on things like conditionals that they're probably not
a useful solution.
* Banning xargs and doing them as functions is a possibility, but far
from ideal, especially since it's just working around a Portage
limitation.
* Making Portage support subprocess dies is the nice solution, but this
probably isn't an EAPI 2 timeframe feature.
In addition, having nonfatal versions of commands is also useful in
practice. Exheres has a 'nonfatal' command, so you can do 'nonfatal
dodoc foo bar baz'. This also needs discussing before deciding upon a
spec.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI-2 do* functions die
В Пнд, 08/09/2008 в 23:34 +, Jorge Manuel B. S. Vicetto пишет:
> So we're talking about adding the following to EAPI-2:
While it's not too late. Can we make dobin, doman and other do*
functions finally die in EAPI=2? I've reviewed discussions on -dev
[1],[2] and bug 138792 [3] and seems that the only possible stopper is
that implementing them as functions makes impossible to use them with
xargs. Maybe for such rather rare case we should create new functions
(xdo{bin,*} or whatever name is better)?
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/40437
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/56443
[3] bugs.gentoo.org/138792
--
Peter.
Re: [gentoo-dev] EAPI-2
Jorge Manuel B. S. Vicetto kirjoitti: and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I won't approve it for use in the tree before it's written as a GLEP in order to avoid the fiasco with EAPI 1 (it's still not documented properly). I can however approve the list of items. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI-2
On Tue, 09 Sep 2008 16:31:08 +0300 Petteri Räty <[EMAIL PROTECTED]> wrote: > Jorge Manuel B. S. Vicetto kirjoitti: > > and cardoe's earlier request to the council ml, can the council > > members discuss this proposal and consider voting it? > > Does anyone have any objections to this proposal? > > I won't approve it for use in the tree before it's written as a GLEP > in order to avoid the fiasco with EAPI 1 (it's still not documented > properly). I can however approve the list of items. What about the PMS EAPI 1 documentation do you consider 'not proper'? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile
Vaeth wrote: Ciaran McCreesh wrote: Having to write an ebuild just to install something in a package manager friendly way and be able to uninstall it cleanly later is a defect No, this is exactly what ebuilds meant for: That the package manager keeps track of your package, and possibly also recompiles it in case of library upgrades. For this reason, ebuilds should essentially just consist of the commands which you would also type in the shell - this information *must* be provided (together with obviously some data like package name, slot-requests, and an otional description), but essentially that should be it. If it is more work or requires more knowledge to write an ebuild, then it is the ebuild concept which is defect. So in your opinion, a future eapi should make ebuilds look closer to this? http://aur.archlinux.org/packages/mplayer/mplayer/PKGBUILD Importare is a very useful and nice tool. I don't understand, that Portage doesn't have something like that, yet. (So they should consider doing something like that.) When I was still using Gentoo, I did a lot of ebuilds for programs which I found out, that they don't work afterwards. Using package.provide isn't really nice either, because it then isn't tracked. With importare, I can first test it, and if it works, make an ebuild/exheres and install that. If you do that, it will automatically upgrade the importare'd package and uninstall any leftovers, just like a normal update. BTW, it is not a PM replacement, it is an addition. You would be considered to be mad if you use importare for everything. Regards, Bernd
Re: [gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile
Ciaran McCreesh wrote: > > Having to write an ebuild just to install something in a package manager > friendly way and be able to uninstall it cleanly later is a defect No, this is exactly what ebuilds meant for: That the package manager keeps track of your package, and possibly also recompiles it in case of library upgrades. For this reason, ebuilds should essentially just consist of the commands which you would also type in the shell - this information *must* be provided (together with obviously some data like package name, slot-requests, and an otional description), but essentially that should be it. If it is more work or requires more knowledge to write an ebuild, then it is the ebuild concept which is defect.
