[gentoo-dev] Re: RFC: PROPERTIES=funky-slots
Patrick Lauer gentoo.org> writes: > > On 06/23/12 21:21, Ciaran McCreesh wrote: > > There's been a move towards using slots for "clever" things that don't > > fit the traditional way of how slots worked. Examples include the new > > gtk2 / gtk3 handling and Ruby gems virtuals. > > > > Aside from being abusive, > No, it solves a real problem. > > this screws things up for Paludis users. > -EDONTCARE, use a supported package manager So if the packagemanager is struggling to resolve whether a package belongs in a slot or not, would this be a case for encoding such metadata in the ebuild filename. foo-slot2-3.2.1.ebuild This way the PM would be able to determine exactly what it has todo before it starts to parse the ebuild
[gentoo-dev] Re: [RFC] base.eclass
Tomáš Chvátal gentoo.org> writes:
>
> Hola,
> I have incorporated all fixes to base.eclass that has been itching me
> for a while (closes both open bugs).
>
> Whats new:
> * base_src_install docs
> this thingie install docs and html_docs from bash array defined in
> global scope (or anywhere else indeed :P)
>
> * all bash variable arrays including the PATCHES one have support for
> folders
>
> * using same codestyle everywhere...
>
> * using pushd/popd instead of cd
>
> Diff and full eclass attached.
>
> Living link:
> http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=eclass/base.eclass
>
There seems to be alot of unquoted variables
65 base_src_util $@
90 case $1 in
95 [[ ! -z "${A}" ]] && unpack ${A}
117 oldval=${EPATCH_SOURCE}
118 EPATCH_SOURCE=${x}
120 EPATCH_SOURCE=${oldval}
Also a typo: an "n" slipped in
130 popd > n/dev/null
[gentoo-dev] Re: Qt3 deprecation and removal policy
Ben de Groot gentoo.org> writes: > > As announced 5 months ago[1], Gentoo's Qt team now officially > deprecates usage of x11-libs/qt:3 and packages depending on this > version of Qt. > > # Policy for remaining ebuilds depending on qt:3 # > > * if Qt3 optional, remove this option > * if Qt4 depending version stable, remove Qt3 depending versions > * if Qt4 depending version in testing, mark stable, then remove older versions > * if no Qt4 version in tree, get Qt4 version in testing by 2010-01-21 > and stable by 2010-02-21 > * if no Qt4 version exists, check for equivalent/replacement packages, > and mask by 2010-02-21 > > Note: for packages that currently have no version marked stable, the > references to stabling Qt4 versions obviously don't apply. > > 1: http://archives.gentoo.org/gentoo-dev-announce/msg_d851e05567d538b662f34de8dfdb7316.xml > > Cheers, QUCS is a qt3 only application. This is a fantastic electrical simulation package and is in active developement. There is a svn branch for the qt4 port but it isn't there yet. Removal of qt3 will break this app that is in the main tree If the policy is to then remove this app (which would be a very big shame since it will mean - based upon past experience - hard to get back in) could a hard-mask live ebuild for the svn/nightly be made until the next qucs is released
[gentoo-dev] Re: Stabilization of Python 3.1
AllenJB allenjb.me.uk> writes: > > As a user who has spent a lot of time on IRC and the forums supporting > other users, I think I can safely say that stabilizing a version of > python which is not supported by portage will end up in a nightmare > scenario. At the very least portage, python-updater and eselect, if not > the majority of the commonly used tools (whichever of gentoolkit, > portage-utils, eix, etc use python), should support python 3.1 before it > goes stable. 1) All those tools (eselect, python-wrapper, python-updater) are written in other languages specifically to ensure a means to update python 2) There has existed for a very long time patches to portage to make it compatible with python3.x Stabilizing Python3.x isn't really an issue as long as some means to ensure people do not emerge -c a python2.x version (eg adding it to the system profile)
[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ciaran McCreesh googlemail.com> writes: > PMS documents what ebuilds may or may not rely upon from the package > manager. PMS, like the Portage document, says that package.mask is a > file. And main tree ebuild can rely on that. There are no directory-based package.mask in the main portage tree > And it shouldn't be until it's gone through the proper process to > become a documented, controlled feature rather than an accident people > are exploiting. > > Seriously, this isn't difficult to do. I get the impression people are > only trying to avoid doing it properly here so they can establish a > precedent of not doing things properly... > And if a developer would like to have it present in the main tree, sure push for an EAPI for it to be available in the main tree. But as a feature that portage has that overlays can use it is useful. Ebuilds in the main tree can still exist safe in the knowledge they won't have this
[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ciaran McCreesh googlemail.com> writes: > > On Thu, 13 Aug 2009 12:50:26 + (UTC) > Mark Bateman soon.com> wrote: > > > On Wed, 12 Aug 2009 20:41:30 +0200 > > > Tomáš Chvátal gentoo.org> wrote: > > > > Also we should allow the stuff as directory thingus (portage > > > > already handles it right). > > > > > > That's a seperate thing that needs EAPI control. You'll need to > > > propose it for EAPI 4 if you want that. > > > > Except this "stuff as directory" was pre-EAPI and thus the PMS should > > have captured that as EAPI-1 > > Ergo PMS is wrong and needs to be updated to refect reality > > PMS accurately reflects the Portage documentation and the commit > message that introduced the feature -- it's purely for use > in /etc/portage/, which is beyond the scope of PMS. > > It is not the business of PMS to enforce undocumented features that > Portage supports only by accident and that aren't used in the tree. > PMS doesn't depict just what portage should do, just what ebuild's in the main tree are to expect. This is a good feature (intentional or not) of portage and is already finding usage in overlays. Sure for such a feature to make it into the main tree EAPI it, but as it stands its fine
[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ciaran McCreesh googlemail.com> writes: > > On Wed, 12 Aug 2009 20:41:30 +0200 > Tomáš Chvátal gentoo.org> wrote: > > Also we should allow the stuff as directory thingus (portage already > > handles it right). > > That's a seperate thing that needs EAPI control. You'll need to propose > it for EAPI 4 if you want that. > Except this "stuff as directory" was pre-EAPI and thus the PMS should have captured that as EAPI-1 Ergo PMS is wrong and needs to be updated to refect reality but back on topic ++
[gentoo-dev] Re: Stats test server running, please check it out
Sebastian Pipping hartwork.org> writes: > > Hello again! > > I have set up a test server of the current stats code. If you have a > minute to check it out that would rock. I'm very interested in overall > feedback and bug reports. > > To check it out please do as following: > > 0) Make sure you have these packages installed: > sys-apps/portage > dev-util/git > dev-python/rhpl > dev-python/urlgrabber > dev-python/simplejson > dev-python/dbus-python > emerge rhpl -va These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N] net-wireless/wireless-tools-29 USE="nls -multicall" 288 kB [ebuild N] dev-python/rhpl-0.213 236 kB Total: 2 packages (2 new), Size of downloads: 523 kB Would you like to merge these packages? [Yes/No] is this correct?
[gentoo-dev] [GLEP] Improvements to the GLEP workflow
ABSTRACT This GLEP details a possible enhancement to the GLEP process to aid the Gentoo council in voting on GLEPs as well Gentoo developers in the creation of GLEPs. MOTIVATION Whenever a developer or user wants to request a significant enhancement to Gentoo the GLEP process can be used to capture the request. Unfortunately all the council can do with GLEPs are either 1) Vote to accept the GLEP 2) Vote to reject the GLEP 3) Defer voting on the GLEP For the majority of GLEPs this process is adequate. This process however becomes a hindrance if a GLEP is submitted that is either incomplete, fairly complex or a general consensus on the best way forward isn't reached. What ends up happening with GLEPs like this is they linger around being tweaked and repeatedly discussed, so much so that eventually nothing new is being discussed and no further constructive discussions occur. SPECIFICATION Rather then having a process of: GLEP editing -> Council voting -> back to editing until a YES/NO vote. If the GLEP is determined to not describe the problem/enhancement/solution enough it should be suspended and a more structured work flow utilised. 1) Capture specification of problem or enhancement. The GLEP shall be re-written such that it ONLY details the problems being faced or details the requested enhancement. Actual details are required, "how foo is presently done" is useless in a years time if someone needs to examine an old GLEP. Details on possible solutions or implementations are not to be included in this section. 2) Specification Approval Once the actual scope of the problem has been defined the council can vote on freezing the scope of the GLEP. 3) Submission of concepts. With the actual scope of the problem detailed and frozen, developers can discuss what concepts should be added to the GLEP. One or more concepts shall be added to the GLEP with enough detail to show how each falls within the scope of the GLEP. Likewise criticisms of each concept shall be added to provide its pros and cons (if more then one solution is to be submitted). Any required modification to the scope needs to be approved by the council. 4) Concept Design Review Once each concept has been detailed enough, the council can then vote to either accept one of the suggested concepts or reject the GLEP. Details of council decision (ie which concept excepted, if any) to be recorded in the GLEP 5) Detailed Design Review. An optional step can be utilised to capture the implementation. A final signoff by individuals actually implementing the concept to confirm the scope of the GLEP has been met. How is this beneficial? By having actual stages to the GLEP process, stages that do not get polluted by discussion/details belonging in a subsequent stage, the content of each stage can be clearly defined so all parties are aware of what is being discussed. This also provides the additional benefit of traceability, so that as old developers leave and new developers arrive, the GLEP is a complete package detailing the problems, the solutions as well as the justification. This removes the reliance on distilling mailing list posts or irc logs after the fact. Likewise it provides a mechanism for individuals to submit a GLEP who may not be fully aware of the best method to implement such an enhancement. Others can then propose concepts that meet this proposal (if such an enhancement is valid). The actual structure of the GLEP template remains largely the same, additions headings would need to be added after the SPECIFICATION heading to provide documentation for the different stages. SPECIFICATION: full breakdown of the problem COUNCIL COMMENTS ON SPECIFICATION: Capture council’s verdict on GLEP preliminary details capturing any additional information on what the council would like to see in concepts or if it should be rejected CONCEPT DESIGNS: Each concept to have its own subheading capturing details of how it plans to solve what has been detailed in the SCOPE of the GLEP CONCEPT_1: DETAILS: CRITIQUE: CONCEPT_2: DETAILS: CRITIQUE: COUNCIL COMMENTS ON CONCEPT: Result of council vote on what the council have chosen, if the council requires additional metrics if there is no clear advantage between different concepts, or if GLEP is rejected. (Optional) DETAILED DESIGN SIGNOFF: A final closing point to the GLEP to capture who fulfilled what and where with respect to the SCOPE Requirement #1 from the SCOPE implement by foo in bar RATIONALE: ...
[gentoo-dev] Re: Gentoo Council Reminder for May 28
Ciaran McCreesh googlemail.com> writes: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, 27 May 2009 22:43:21 +0100 > Roy Bamford gentoo.org> wrote: > > You chose to ignore "Adding metadata to the filename is not required > > and is bad system design practice." > > > > I assume you agree with that as you chose to snip it, not to refute > > it with a technical argument? > > That's a blind assertion, not a technical argument, in the same way > that "feeding cows is not necessary, and giving food to cows is bad > farming practice" is. The GLEP clearly demonstrates its necessity. The only thing that GLEP55 "clearly demonstrates" is something has to be done, such that the EAPI of the ebuild can be determined before the package manager actually sources the ebuild. NOT once within GLEP55 or in all the ml posts over all the *MONTHS* has there been unequivocal proof that encoding metadata into the filename of an ebuild is a necessity, so please stop playing that tune it is getting boring > > > GLEP 55 is a poor piece of technical writing. The title > > > > Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) > > > > should be an area to be impvoved not a possible solution that has not > > even been discussed (in the document) yet. > > GLEP titles are required to be short. Even with title length restrictions the title can easily be improved. At present it tells the skim reader NOTHING except it is todo with encoding EAPI into the filename. "Means to determine EAPI of ebuild" 7 less characters AND actually provides some description of what this GLEP is going to cover not some BS "WTF" title. Present title is crap, simple as that. > > > The abstract tells readers more about a proposed solution. > > > > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds > > (for example, foo-1.2.3.ebuild-1). > > > > and readers still don't know the problem that it tries to address. > > Because that's down in the 'Problem' section. Your argument appears to > be that no individual paragraph covers every last bit of material in > the GLEP. > No it is not. That is not an abstract, that is jumping straight in with the proposed solution. That is not what an abstraction/summary is for. There is no (formal) length restriction on the abstraction section so it should be taken advantage of. The abstract/summary is to allow those that have a quick look into the paper (after looking at a relevant title...) to tell if it relevant to their interest and whether they should read any further. OR in a big discussion, where a paper is referred to as a logging number, people can quickly ascertain what it is discussing - very important ifmany papers are referenced in a discussion If you have any formal proposal writing experience you would know that As a formal paper this is a joke and I would be embarrassed to be associated with it, luckily I am not. > > The statement of the problem is not entirely correct either ... > > The current way of specifying the EAPI in ebuilds is flawed. > > In order to get the EAPI the package manager needs to source the > > ebuild, > > > > Nope, in order to get the EAPI, the PM needs to parse the ebuild, it > > need not source it. Thats a statement of the current design. > > Uhm. No. With the current rules, the package manager cannot parse the > ebuild. It has to use a full bash source. So ... maybe the rules are wrong and they also need to be changed for the complete solution to be realised. Parse the ebuild, determine the EAPI, configure PackageManager, source ebuild. Problem solved. QED. I wonder what portage does at the moment... Definition of problem is flawed within GLEP55 > > > > > which itself needs the EAPI in the first place. > > > > Well, thats what current designs do, its a design than can be changed. > > ...which is what GLEP 55 is about, yes. > > > Until we get to the Abstract solution, the GLEP reads like a sales > > brouchre, which is what reminded me of VHS vs Betamax. > > Have you ever read a technical paper? They start off with a brief > introduction that doesn't contain details, then move on to the details > later on. > WHAT! 1) The title of this GLEP is all about the solution 2) the Abstraction is all about the solution THEN finally we get the actual problem This GLEP starts off with DETAILS!!! precise details Again this, as a technical paper is shocking!. And if you have read any technical paper or written any that actually got anywhere you would be able to see that. > > The > > > > Hurts performance: yes > > > > needs to be quantifed and included in the GLEP, so that readers can > > make an impartial objective assessment of the alternatives on offer > > and hopefully support the best technical solution. That need not be > > the fastest. > > It's a simple statement of fact. if it *fact* provide results, provide details of how the results were obtained, provide details so others may r
[gentoo-dev] Re: RFC: Gentoo Support Everywhere
Jesús Guerrero terra.es> writes: > > > On Wed, May 20, 2009 00:40, Duncan wrote: > > Jesús Guerrero terra.es> posted > > f7f0028fed7284065d82b976e721ec3a.squirrel jesgue.homelinux.org, > I've checked it lots of times, and it's there. It's in the "Moderators" > subforum, and it's near to the top of the list on that subforum so if > you can access that subforum you shouldn't have a problem finding it, > since linuxquestions is in the title. > Umm *only* Forum Moderators and forum admins can view that sekrit section of the forums. Its not even linked for anyone else
[gentoo-dev] Re: The fallacies of GLEP55
Ciaran McCreesh googlemail.com> writes: > > On Sat, 16 May 2009 21:58:10 + (UTC) > Mark Bateman soon.com> wrote: > > "The current way of specifying the EAPI in ebuilds is flawed" > > That is not defining the problem, that is an opening statement. > > That is the problem. No, that is a summary of the problem. Not once has the actual problem been described or documented. It has been requested multiple times by multiple people and yet a description detailing the problem has yet to materialise. Repeated use of *problem* doesn't suddenly expand on the definition of the word *problem* to encompass details needed in a technical proposal within a GLEP. If you do not understand the problems associated with determining the EAPI of an ebuild before sourcing it, please stop championing this GLEP until someone does provide a complete breakdown of the process. Until such information is provided continued discussion of this GLEP is not going to progress since words like *obviously* are substituted for actual facts, a substitution which does not provide anything new to this discussion > > "In order to get the EAPI the package manager needs to source the > > ebuild, which itself needs the EAPI in the first place." > > It then describes "a" mechanism utilising an ebuild > > (source /usr/portage...) to obtain the EAPI from within the ebuild > > (EAPI=...). Using this method the entire content of GLEP55 is > > accurate. > > > > However, this is not the only method to determine the EAPI of an > > ebuild that exists and as such the viability of GLEP55 as the best > > solution is brought into question > > Yes, it is the only method. No it is the only method you are willing to accept, there is a big difference. Many people have mentioned in passing other means of determining the EAPI of an ebuild pre-sourcing (thus allowing the PM to source the correct eclass or flag up warnings...) YET they have just been shot down with no actual technical reason, except "they do not involve coding the EAPI into the filename". Please provide detailed technical description of the problem, as has been requested by a number of people, as well as providing details of why in-filename encoding of EAPI is technically as well as practically the best solution. > > > Where is it defined that the ebuild must be sourced 1st? > > Why does the ebuild have to be sourced 1st? > > Such things are obviously true to anyone with a basic understanding of > the domain. So you are unable to actually reference any credible source of information to back up your claims then. > > > GLEP55 explicitly states that the EAPI to be recorded in the file > > extension, while, as this thread has shown, a number of methods can > > be used to source the EAPI version of the ebuild *without* the need > > of actually source'ing the ebuild (grep, sed, metacache) all of which > > are viable solutions to the problem, the problem that is so obvious > > it doesn't actually have to be defined > > Except that that isn't true. With the current rules, an ebuild has to > be sourced to get EAPI. And you can't just say "use the metadata > cache", since the package manager has to know how to generate the > metadata cache in the first place. > > Please make sure you're familiar with the basics of how metadata works > before commenting any further. > What has my understanding or lack of understanding of "metadata" have to do with my statement that other means exist to determine the EAPI of an ebuild before sourcing said ebuild? This is meant to be a discussion about "The fallacies of GLEP55" Refusal to accept any other possible solution as well as refusal to discuss any other solution to the problem, all wrapped up in an awe of supremacy on the matter (without ONCE providing details) is not beneficial to Gentoo in finding the best solution. Simple fact is there are many methods available to determine the EAPI of an ebuild without having to encode it in the filename (or its extension). In fact you yourself have mentioned that eclasses change the EAPI http://article.gmane.org/gmane.linux.gentoo.devel/61255 "But eclasses have tried changing it. This is something people have done, not some hypothetical." So the need to have it actually encoded in the filename is not needed, since other method's of actually setting the EAPI exist and work. Blindly dismissing a solution without actually providing any technical information of the problem AS well as why a *proposed* solution isn't the best is of no benefit to solving the problem For instance SheBangs are very useful FILE:test1.py #!/usr/bin/python2.5 #-*- coding: utf-8 -*- def bin(number,count):
[gentoo-dev] Re: The fallacies of GLEP55
Patrick Lauer gentoo.org> writes:
>
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
>
> The proposed solution to a problem that is never refined, in short, is to add
> the EAPI into the ebuild filename "to make things easier". Which is a rather
> unsubstantiated idea that doesn't really add up if you look at it ... and it
> adds some artifacts that we've been laughing about for a decade because
> microsoft did the exact same thing (binding the executable-ness of a file to
> the filename).
>
The problem isn't GLEP55 (as such), it is a bit more subtle then that and runs
deeper then just this GLEP.
For starters it is the whole GLEP process
GLEP [Gentoo Linux Enhancement Proposals] is meant as a central place to pull
*proposals* that provide enhancements to Gentoo.
Some are quite self-apparent (GLEP08)
others are a bit more... lacking (GLEP55)
Why is GLEP55 lacking? because it providing a "solution" to a problem that is
not actually defined
"The current way of specifying the EAPI in ebuilds is flawed"
That is not defining the problem, that is an opening statement.
"In order to get the EAPI the package manager needs to source the ebuild, which
itself needs the EAPI in the first place."
It then describes "a" mechanism utilising an ebuild (source /usr/portage...) to
obtain the EAPI from within the ebuild (EAPI=...). Using this method the entire
content of GLEP55 is accurate.
However, this is not the only method to determine the EAPI of an ebuild that
exists and as such the viability of GLEP55 as the best solution is brought into
question
Where is it defined that the ebuild must be sourced 1st?
Why does the ebuild have to be sourced 1st?
This then results in ml participants taking this GLEP as the *only* solution
(to a problem that hasn't actually been defined...) with statements like
"That's *obviously* completely wrong"
If something was so obvious this GLEP would have been approved/rejected by now,
but it hasn't because the problem isn't defined "because it is obvious"
If a problem cannot be describe then the problem is not understood by the one
writing about the problem.
The GLEP process needs to be refined such that some means of initially raising
a problem (be it a GLEP itself) that describes the problem in as much detail as
possible. Once said GLEP has been accepted, ie the problem is acknowledged,
(sub) GLEP's can be submitted providing possible solutions to the problem.
This way the problems encounted with this particular GLEP, a GLEP that keeps on
re-surfacing, would be minimised
GLEP55 explicitly states that the EAPI to be recorded in the file extension,
while, as this thread has shown, a number of methods can be used to source the
EAPI version of the ebuild *without* the need of actually source'ing the ebuild
(grep, sed, metacache) all of which are viable solutions to the problem, the
problem that is so obvious it doesn't actually have to be defined
Thing is the package manager *needs* to know the EAPI that the ebuild complies
to before it can source it to ensure
1) the correct EAPI-specific eclass is inherited
2) Package manager needs to protect itself from ebuild syntax that earlier
system packages (eg bash) would fail with
So please just reject GLEP55, not because its wrong but because it is
incomplete
reject GLEP55 and have a GLEP62 submitted which defines the problem, then
request GLEP62-{1,2,3...} be submitted providing possible solutions to the
problem. GLEP55 can then be submitted as a possible solution. Then
developers/council can vote on the sub-GLEP's to choose which solution is the
best technically as well as what is best for the users (dev's and general
users)
Traceability of issues and solutions is needed, traceability that extends
beyond mailing-lists and irc logs (discussion mediums which are good for
instantaneous discussion of issues, but are rubbish for returning to an issue a
few years down the line, no matter how many logs exist). Report the problem
better
How clear is it from the stored infomation available whether EAPI's when they
were 1st conceived and added to portage/paludis/pkgcore was the best solution
to the problem of expanding on ebuild capability. Or more to the point was how
it was done partly responsible for the mess we are in now?
If the problem on ebuild expansion was better documented and defined, maybe
this GLEP wouldn't even exist, we may have been already using *.ebuild-3
because it was the best solution
