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] Multislot dependencies
Tiziano Müller schrieb: Hi everyone I'd like to bring bug #229521 to your attention and see whether we can come up with a solution for it. The problem: A package foo depends on a slotted package bar _and_ more than one slot of bar can satisfy this dependency. Why this is a problem: If the dependency looks like one of the following: * DEPEND==cat/bar-2 * DEPEND==cat/bar-3 * DEPEND=|| ( cat/bar:2 cat/bar:3 ) then the package manager doesn't know after building foo which slot of bar has been used to build foo. On the other hand might this information be needed to debug problems with package foo. The problem gets even worse as soon as RDEPEND comes in: (assuming the same examples from above but with RDEPEND) * The package manager currently doesn't record which slot has been used and can't therefore track whether the user will destroy something in case he uninstalls one of the slots of bar * The package manager can't sanely consider whether an update for a slot is actually needed There is a section in PMS, that tries to address this. = Slot Dependencies A named slot dependency consists of a colon followed by a slot name. A specification with a named slot dependency matches only if the slot of the matched package is equal to the slot specified. If the slot of the package to match cannot be determined (e.g. because it is not a supported EAPI), the match is treated as unsuccessful. An operator slot dependency consists of a colon followed by one of the following operators: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. = Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will break unless a matching package with slot equal to the slot of the best installed version at the time the package was installed is available. To implement the equals slot operator, the package manager will need to store the slot of the best installed version of the matching package. The package manager may do this by appending the appropriate slot after the equals sign when saving the package’s dependencies. This syntax is only for package manager use and must not be used by ebuilds. = So, if you go with that, the dependency would look like this: DEPEND==cat/bar-2:= That means, that it accepts any slot of versions above version 2, but restricts it to the slot it has been built against, at runtime. The combination of = and := might look a bit ugly, so maybe it might indeed be useful to specify a way to provide a list of slots. But it would work in most cases. Regards, Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Multislot dependencies
Tiziano Müller schrieb: Bernd Steinhauser wrote: Tiziano Müller schrieb: Hi everyone I'd like to bring bug #229521 to your attention and see whether we can come up with a solution for it. The problem: A package foo depends on a slotted package bar _and_ more than one slot of bar can satisfy this dependency. Why this is a problem: If the dependency looks like one of the following: * DEPEND==cat/bar-2 * DEPEND==cat/bar-3 * DEPEND=|| ( cat/bar:2 cat/bar:3 ) then the package manager doesn't know after building foo which slot of bar has been used to build foo. On the other hand might this information be needed to debug problems with package foo. The problem gets even worse as soon as RDEPEND comes in: (assuming the same examples from above but with RDEPEND) * The package manager currently doesn't record which slot has been used and can't therefore track whether the user will destroy something in case he uninstalls one of the slots of bar * The package manager can't sanely consider whether an update for a slot is actually needed There is a section in PMS, that tries to address this. = Slot Dependencies A named slot dependency consists of a colon followed by a slot name. A specification with a named slot dependency matches only if the slot of the matched package is equal to the slot specified. If the slot of the package to match cannot be determined (e.g. because it is not a supported EAPI), the match is treated as unsuccessful. An operator slot dependency consists of a colon followed by one of the following operators: * Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will not break if the matched package is uninstalled and replaced by a different matching package in a different slot. = Indicates that any slot value is acceptable. In addition, for runtime dependencies, indicates that the package will break unless a matching package with slot equal to the slot of the best installed version at the time the package was installed is available. To implement the equals slot operator, the package manager will need to store the slot of the best installed version of the matching package. The package manager may do this by appending the appropriate slot after the equals sign when saving the package?s dependencies. This syntax is only for package manager use and must not be used by ebuilds. = So, if you go with that, the dependency would look like this: DEPEND==cat/bar-2:= That means, that it accepts any slot of versions above version 2, but restricts it to the slot it has been built against, at runtime. The combination of = and := might look a bit ugly, so maybe it might indeed be useful to specify a way to provide a list of slots. But it would work in most cases. hmm, this is kdebuild-1... Indeed, but it is a proposal. I miss two things here: a) What happens in case of DEPEND=, RDEPEND==cat/bar-2:= ? Is that defined? If yes, what does it mean? If not, what shall be the package managers behaviour? I don't think, that RDEPEND matters here. If a dep is not in DEPEND, that means, that it doesn't affect the build process of the package. So in case the dep spec matches more than one slot, the package should be able to use both without a rebuild. (Which means, that the package manager can switch the dep.) If changing the slot would mean, that a rebuild is required, then the dep affects the package at build time and should be in DEPEND. b) It is not said that a package depending on || ( cat/bar:2 cat/bar:3 ) then really uses cat/bar:3 if available, it might as well use cat/bar:2 for one reason or another. It might be clearer if we have slots named stable, unstable. In such a case a package depending on cat/bar might decided to use cat/bar:stable if available instead of cat/bar:unstable. So, the spec should either state that the package must use the best matching version or we need another way for such cases, like a function to explicitly tell the pm which slot has been used. Not sure if that is a good idea, because you would expect, that those slot assignments (assuming you mean stable and unstable as list of slots) get changed if a different slot is now stable and that would break previous assignments. BTW, you can already name a slot unstable-2 or similar. KDE 4.0 has slot kde-4, for example. Regarding the || ( cat/bar:2 cat/bar:3 ) construction, if a package manager chooses one out of the two, it should restrict the package to this dep at runtime. Not sure how the several package managers handle this, tbh. I think that problem a) is a bit nasty, but it might become better if we'd split the dependency variables into DEPEND, RDEPEND, C(OMMON_)DEPEND (where the last one would be used for packages needed at compile time and runtime). I would rather vote for labels, which clear the whole dependency thing up a bit and doesn't splatter them over several vars. Unfortunately that is not compatible
Re: [gentoo-dev] Re: Re: Multislot dependencies
Tiziano Müller schrieb:
Bernd Steinhauser wrote:
Tiziano Müller schrieb:
Bernd Steinhauser wrote:
Tiziano Müller schrieb:
Hi everyone
I'd like to bring bug #229521 to your attention and see whether we can
come up with a solution for it.
The problem:
A package foo depends on a slotted package bar _and_ more than one
slot of bar can satisfy this dependency.
Why this is a problem:
If the dependency looks like one of the following:
* DEPEND==cat/bar-2
* DEPEND==cat/bar-3
* DEPEND=|| ( cat/bar:2 cat/bar:3 )
then the package manager doesn't know after building foo which slot
of bar has been used to build foo. On the other hand might this
information be needed to debug problems with package foo.
The problem gets even worse as soon as RDEPEND comes in:
(assuming the same examples from above but with RDEPEND)
* The package manager currently doesn't record which slot has been used
and can't therefore track whether the user will destroy something in
case he uninstalls one of the slots of bar
* The package manager can't sanely consider whether an update for a
slot is actually needed
There is a section in PMS, that tries to address this.
=
Slot Dependencies
A named slot dependency consists of a colon followed by a slot name. A
specification with
a named slot dependency matches only if the slot of the matched package
is equal to the slot
specified. If the slot of the package to match cannot be determined
(e.g. because it is not a
supported EAPI), the match is treated as unsuccessful.
An operator slot dependency consists of a colon followed by one of the
following operators:
* Indicates that any slot value is acceptable. In addition, for runtime
dependencies, indicates
that the package will not break if the matched package is uninstalled
and replaced by a
different matching package in a different slot.
= Indicates that any slot value is acceptable. In addition, for runtime
dependencies, indicates
that the package will break unless a matching package with slot equal to
the slot of the
best installed version at the time the package was installed is
available. To implement the equals slot operator, the package manager
will need to store the slot of the
best installed version of the matching package. The package manager may
do this by appending
the appropriate slot after the equals sign when saving the package?s
dependencies. This syntax
is only for package manager use and must not be used by ebuilds.
=
So, if you go with that, the dependency would look like this:
DEPEND==cat/bar-2:=
That means, that it accepts any slot of versions above version 2, but
restricts it to the slot it has been built against, at runtime.
The combination of = and := might look a bit ugly, so maybe it might
indeed be useful to specify a way to provide a list of slots.
But it would work in most cases.
hmm, this is kdebuild-1...
Indeed, but it is a proposal.
I miss two things here:
a) What happens in case of DEPEND=, RDEPEND==cat/bar-2:= ? Is that
defined? If yes, what does it mean? If not, what shall be the package
managers behaviour?
I don't think, that RDEPEND matters here.
If a dep is not in DEPEND, that means, that it doesn't affect the build
process of the package. So in case the dep spec matches more than one
slot, the package should be able to use both without a rebuild.
(Which means, that the package manager can switch the dep.)
If changing the slot would mean, that a rebuild is required, then the
dep affects the package at build time and should be in DEPEND.
Oh, my point is much simpler:
The kdebuild-1 spec says: [...] that the package will break unless a
matching package with slot equal to the slot of the best installed version
at the time the package was installed is available.
But: RDEPEND doesn't have to be evaluated before installing the package and
DEPEND doesn't contain this package. So, there is no record of such a
package. What now?
tbh, I don't get what you are on about.
The slot restrictions only matter in cases where a rebuild what be
required, because the package would break, if you change the installed
slot. But in that case the dep affects runtime and should be in DEPEND.
For runtime-only deps, the package manager should be allowed to change
the slot, if multiple slots are allowed.
Regarding the || ( cat/bar:2 cat/bar:3 ) construction, if a package
manager chooses one out of the two, it should restrict the package to
this dep at runtime.
Hmm, this is the point: What happens if the package chooses cat/bar:2 to
link against and the package manager records cat/bar:3 since it assumes
this is the better match? Is it it allowed to do the following (it's an
example):
DEPEND=|| ( sys-libs/db:4.5 sys-libs/db:4.6 )
pkg_setup() {
DB_VER=
# both major versions work but prefer 4.5 if available
has_version sys-libs/db:4.5 DB_VER=4.5
}
Questions:
a) should DEPEND be valid?
b) will has_version evaluate to true?
c) how will the pm know that the package chose sys
Re: [gentoo-dev] [EMAIL PROTECTED]
Benedikt Morbach schrieb: ++ I'm a user too and I really find it annoying that one can't read this list to keep up with recent development, without digging to tons of FUD, insults and other crap. I personally came to the conclusion that it is best to simply ignore all mails from certain people (hint: Most of them were forcibly retired and work on an alternative package manager and a certain dokument where they try to set gentoo standards from the outside.) I found out, that you loose nearly nothing by completely ignoring these people. What especially makes me sad is, that there are so many people here feeding the trolls. (And yes, sometimes I can't even hold myself back) In a perfect world, it, would be enough to look at one side of the thing. (Yeah, maybe in a perfect world, there would be no need to deal with stuff like this.) But this isn't a perfect world. So please don't make the mistake an go through this only reading it the way you want to see it. The problem with that kind of threads normally is, that people on both(!) sides would rather cut their leg off than admitting, that the other person might be right. (Not judging who was right, I have my opinion about it, but you might already know that.) Yes, there have been personal insults, but again on both sides and I would rather have hoped, that this wouldn't have happened. But again, this wasn't a one-side matter. You mention tons of FUD. That is a really strong phrase and to be honest, I didn't see FUD from the Paludis folks. There was some mess about this Pkgcore bug, but that wasn't actually FUD, but the truth, which unfortunately turned into a really ugly thing. (And maybe got more attention than it deserved.) Now I guess that someone will reply to me, that this is off-topic on this list, which obviously nobody will answer you. But keep it low, no need to start over again. ;-) Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
Patrick Lauer schrieb: On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote: That's what metadata is there for. And ebuilds don't mind carrying a bit more ... after all it's just one line of text. So, what you want to do is to read every ebuild, if you want to find all live ebuilds? Metadata cache. It's there for a reason. Still a lot slower. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: A few questions to our nominees
Patrick Lauer schrieb: On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote: That's what metadata is there for. And ebuilds don't mind carrying a bit more ... after all it's just one line of text. So, what you want to do is to read every ebuild, if you want to find all live ebuilds? Metadata cache. It's there for a reason. Besides, what will you do to determine if an installed ebuild is a live one? Go through the metadata cache for the non-installed stuff? Go through these ebuilds? Sounds like fun... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Luca Barbato schrieb: Bernd Steinhauser wrote: In the -scm approach this means: trunk = -scm 4.1 branch = -4.1-scm so you'll be oblivious of changes needed inside the ebuild and you won't know what you merged last time you issued an emerge =foo-scm (that by itself it is a problem, since it is ambiguous) Huh? What has to do with the ordering? And finding out what I installed last time is trivial and not the point. With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. trunk = .live nope it would resolve as foo_pre1 - meaningless. 4.1 branch = 4.1.1.live (before 4.1.1 has been released) correct, you can keep tracking 4.1.1, have interim snapshot pushed in portage to ~ if you are confident about them. Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. I have got a feeling, that you didn't have to deal with live packages that much yet. (No offense.) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill schrieb: On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato [EMAIL PROTECTED] wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. No, the idea behind ESCM_LOGDIR was different. If you just want the revision of the current installed thing, you can grep through the environment. ESCM_LOGDIR mainly aimed to provide a history of revisions you installed. So that you can then tell upstream Hey, I have this revision installed and it doesn't work, but this revision worked.. So it is definitely related, but not the same. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Luca Barbato schrieb: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. Wow, impressive. Actually, you can't be serious... Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. If you want to track something you write a template for such thing, you just need to put a meaningful name, portage won't care if foo-0.live is really bar branch baz from repo dup. Advanced testers should be able to pick the live template and help testing and should be able to smoothly update, I'm all for it. See, the problem here is, that, I have been using -scm as proposed in GLEP 54 for quite some time now and it works very well. I just don't see any benefit from your proposal, on the contrary there are issues. And that includes the ordering. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? Talking away problems, now that is a way to handle QA. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Patrick Lauer schrieb: Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? No, it's just unsubstantiated rumors. As such they are irrelevant until some kind of proof is shown. It might be, but it might also be a bug. Of course the maintainers can choose if they go after it. BTW: The Paludis maintainers did have a look at the security hole you pointed out, even though everyone knows, that you spread lies about Paludis... Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? It is too generic and doesn't even describe the class of bug. By the same rationale portage and paludis have multiple bugs ... It is indeed generic, but then you should test every part of EAPI. The main point was, that test are missing and the fact, that there is might be a bug, that they didn't catch yet is a follow up. Of course, filing a bug report for a single issue might get that issue fixed, but what caused this issue to be still there (missing tests) will still be there. Talking away problems, now that is a way to handle QA. So, could anyone just actually mention what the problem is, or is the hivemind not able to express such a simple thing? Just think of the thousands of emails, being read by hundreds of readers, that have cost so much time ... in that time you could have written a patch and a bugreport. Again, one patch and one bug report wouldn't wipe out the problem in the long term view. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Luca Barbato schrieb: Bernd Steinhauser wrote: Luca Barbato schrieb: Ciaran McCreesh wrote: The point is to make pkgcore a better package manager by getting the developers to do some basic testing. We're not talking some obscure, weird bug here. We're talking a really obvious, major screwup that a couple of quick unit tests would catch straight away. No, you aren't talking, you are babbling about undefined flaws that nobody can evaluate, for which you aren't providing a way to reproduce it and possibly doesn't exist. lu So in your opinion, the pkgcore maintainers should just say Screw it, it was just Ciaran who said that. and move on? He doesn't point any issue in particular. And that wasn't the point. He pointed out, that there is an issue, that hasn't been caught because of missing tests. Why is Create tests for EAPI=1 stuff. not a way to describe how to reproduce a problem? because EAPI1 isn't specified completely so you don't have a large field to cover but you also do not know the bounds of it. It really doesn't matter how it is specified. You have an implementation of it and should make sure, that this implementation works. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Luca Barbato schrieb: Piotr Jaroszyński wrote: The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So we add a new repo each time a new EAPI comes out? Sounds like a big mess. It isn't you just keep 2 repos, one with the minimal eapi and the minimal set of ebuilds needed to upgrade, one with the latest and greatest. lu Then you could also just provide binaries... But lets face it, it slows down progress, because you will delay every change, because stuff like that you will only do if necessary. And it is still huge pain, from a users point of view, to upgrade stuff. And that is, what this is about, making EAPI bumps as less painful as possible. The filename is the easiest solution for that. I really fail to see the point, why it is so important, that the extension will still be .ebuild in the future. There is a lot of software, that keeps using the same filename for different versions of stuff and in many cases, that is a huge mess. I still haven't seen any good reasons against it. And btw, the KDE overlay users don't seem at all to be confused, because the packages are named .kdebuild-1 instead of .ebuild. Portage (and other tools) keeps happily ignoring them, like it should. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Joe Peterson schrieb: Bernd Steinhauser wrote: And that is, what this is about, making EAPI bumps as less painful as possible. The filename is the easiest solution for that. In any design, there are easy short-cuts that can be taken. But sometimes these short-cuts break paradigms that are fundamental. If you wanted, you could throw a bunch of things into the filename and make it 255 characters long to avoid reading the file, but that clearly would be a pretty bad design. Yes, in principle you could do that, but in principle you could do the same with the first line in a file or whatever you are suggesting. I really fail to see the point, why it is so important, that the extension will still be .ebuild in the future. There is a lot of software, that keeps using the same filename for different versions of stuff and in many cases, that is a huge mess. Is the huge mess you are thinking of the basic reality that software of any reasonable complexity needs to deal with file formats evolving? If so, that is exactly why EAPIs now are being introduced. But almost all software deals with this transparently - no need to expose it to the user, and sticking the version in the filename is both fragile (renaming the file can alter it) and seems like a hack. Wow, altering the content of a file can alter it, too. What is the point there? BTW, so you are suggesting, that we shouldn't put the PV in the file name? We shouldn't put the revision in the file name? Hm, so in the future, there will be a metadata.xml file, that defines: - EAPI - PV - KEYWORDS - more stuff of the ebuild? Sounds complicated. I still haven't seen any good reasons against it. I realize that there are two camps of people here. One camp sees mangling the filename extension as an undesirable way to deal with this, and the other camp simply sees no problem with this. Seems to be like that. But I am really impress, how far some people go, to avoid renaming the file extension of a file. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
Joe Peterson schrieb: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 19:49:08 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Because that is about the same damage (file ext. changes, people might get confused etc.) with less capabilities. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. You completely miss the point of the GLEP. We need new extensions precisely because current package managers can't handle future EAPIs cleanly, and we need to carry on using new extensions because otherwise we restrict what future EAPIs can do. No, I get that. But once you develop the concept of an EAPI, the very next package manager version can be aware of it and check the EAPI of an ebuild. If the ebuild specifies none, then it is old-style. If it specifies one that is unknown or newer than what that package manager version knows it can handle, it can handle that case (ignore it or whatever). I don't see why you need to keep bumping the filename/extension every time it changes from that point forward. Because you can change the EAPI in a way that that may not work anymore. Specifying the EAPI outside the actual ebuild is more flexible. It doesn't have to be the file extension, but that is the obvious solution. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. The user can delve into it as much as needed or desired, but if there are these mysterious EAPI numbers tacked onto the extensions, then it's an added complication that is not important to all users. No, not really. If you have .txt, .txt-2, .text or .footext in a dir, you would still realize, that those should be text files. Of course, a future EAPI could be named .whatevercomestoyourmind, but first, you can expect people to be smart enough to not do that and second, you can still identify the packages, because they are still named foo-version.whatevercomestoyourmind. Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Ciaran McCreesh schrieb: What all are blocks used for? a) Marking that two unrelated packages are mutually incompatible at runtime because they happen to collide, for example on a commonly named executable. b) Marking that two related implementations are mutually incompatible at runtime because they both provide the same binary. c) Marking that a file that used to be provided by one package is now provided by another package that is either depending upon or depended upon by the original package. d) Marking that a package has been moved into another package. Are there any other uses? For future EAPIs, being able to tell the package manager that your block is of one of the types above will help the package manager smooth out the upgrade path for users. For example, for class d) blocks such as the recent coreutils / mktemp mess, the package manager can suggest to the user to install the new package and then uninstall the old package, rather than forcing the user to uninstall the old package by hand (possibly leaving their system without critical utilities) and then install the new package. I strongly suspect that in many (but not all) cases the package manager could be making users' lives a lot easier than it currently is... There is another case. e) A package needs a newer version of another package, but doesn't depend on it. This was the case with KDE4. kdelibs-4.0.x block these packages: !kde-base/kdebase-3.5.7-r6 !kde-base/kdebase-startkde-3.5.7-r1 !=kde-base/kdebase-3.5.8 !=kde-base/kdebase-3.5.8-r1 !=kde-base/kdebase-3.5.8-r2 !=kde-base/kdebase-startkde-3.5.8 The reason is, that a newer revision has to be installed. (But of course kdelibs-4.0.x can't depend on a kde3 package.) So in this case the behaviour would be different ((keyword and) upgrade one package, then install the other package) and the given block reason would be different. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] FYI clarifications to skel.ebuild EAPI usage
Petteri Räty schrieb: solar reported that he had ebuild submissions blindly using EAPI=1 so we hopefully made the text better reflect that it should not be used unless absolutely needed. Regards, Petteri # Eclasses will test for this variable if they need to use EAPI 0 features. -# Ebuilds should not define EAPI=1 unless they need to use features added -# in that version. -#EAPI=1 +# Ebuilds should not define EAPI 0 unless they absolutely need to use +# features added in that version. +#EAPI=0 This is misleading. You should not use the term EAPI 0 here, because ebuild writers will think, that the variable can be tested this way, which is wrong. Although for ebuilds this isn't really important, it still is wrong. ;) Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
Roy Marples schrieb: On Friday 29 February 2008 16:15:51 Ed W wrote: On the other hand since there still isn't a masked ebuild in portage (and I seem some notes on my on Roy's site) then I have to assume that in fact we are still a good way away from calling it a replacement and starting to push it out to users? It's actually been very stable and usable for a long time. It's not, and never will be a 100% drop in replacement for everything baselayout provides, but it's very very compatible. What about the timezone? Baselayout had a setting for the timezone in /etc/conf.d/clock. baselayout-2.0.0 + openrc doesn't seem to have that. Not needed? Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Baselayout-2 progress?
Duncan schrieb: Bernd Steinhauser [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Mar 2008 23:50:09 +0100: What about the timezone? Baselayout had a setting for the timezone in /etc/conf.d/clock. baselayout-2.0.0 + openrc doesn't seem to have that. Not needed? Not needed indeed. The previous setting caused confusion because changing it didn't actually change the timezone (this isn't the place for the technical details). Now, the clock config file simply sets local or UTC, while the timezone is set using the standard glibc /etc/localtime - /usr/share/zoneinfo/ whatever-zone symlink or the TZ environmental variable (see the tzset and hwclock manpages among others). Then there should be a note, that this setting is deprecated. Currently it only says: 'If you want to manage /etc/localtime yourself, set this to .' If there is a note, that this setting isn't used anymore it won't make users, that still have it set wonder why an etc update wants to remove it. Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Keyword request interface (SoC candidate?)
Santiago M. Mola schrieb: I splitted this from the SoC thread so the possible discussion doesn't add noise to the original thread. On Tue, Feb 26, 2008 at 7:32 PM, joshua jackson [EMAIL PROTECTED] wrote: Google is once again doing the summer of code for students. I'm helping organize it this year and am putting out a call for some elements to help. 1) We need idea's for things to do. Diego has already submitted some via his blog which have been taken into consideration. A lot of users don't feel comfortable using Bugzilla and often are lost with our procedures for keyword (both ~ and stable) requests. I think we could use an easy web interface for requesting specific keywords for packages in a point-and-click fashion. So the user would just pick a package from the list, and check some boxes with the arch(es) she want to see in ~arch or stable. Then ATs could go for the ones that met the requirements, and even prioritize stabilisations depending on the number of users who have requested it. I've been talking about it with some users and everyone agrees that they would like to have such an interface... What do you think about? Would it be easy to integrate it with packages.g.o or should it belong somewhere else? Do you think this is a suitable project for SoC? Regards, Santiago Maybe you are looking for something similar to the Wine app database? http://appdb.winehq.org/objectManager.php?sClass=versioniId=3755 Of course not the same, but similar. I do think, that something like this could integrate in a very nice way into packages.gentoo.org. The nice thing about that would also be, that you have a nice overview over the packages(versions), that have a keyword. Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Keyword amd64 - x86_64
Fabian Groffen schrieb: Though, if for instance amd64-fbsd would be introduced, Will that happen? (Asking because I might be interested in testing such a setup.) I think this keyword should have something more generic arch instead, like the x64 we use in prefix now Wouldn't it be more clean if it is amd64 just like the Linux one? Because the arch basically is the same. I think that amd64(-linux) -- x86_64-fbsd x86(-linux) -- x86-fbsd would be more confusing than amd64(-linux) -- amd64-fbsd x86(-linux) -- x86-fbsd Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
Donnie Berkholz schrieb: On 23:39 Fri 15 Feb , Bo Ørsted Andresen wrote: For quite a while the KDE herd has had a modified version of subversion.eclass in the kde overlay. During that time we have added the following features to the eclass which we would like to put back in gentoo-x86 soon. Since the changes are fairly extensive we decided to send it to this list for review first. 1) ESVN_REVISION (before this people had to use ESVN_OPTIONS for this purpose). 2) ESVN_OFFLINE which disables svn up. 3) ESVN_UP_FREQ which uses GNU find to determine if the specified number of hours has passed and only do svn up if it has. This is currently used in the kde4svn-meta eclass for split kde ebuilds that use the same checkout of each module. 4) ESCM_LOGDIR for logging which revisions packages get installed with. See [1]. Users need to explicitly enable this feature to use it. Other than this the eclass has been documented for use with eclass-manpages. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/54233 Some of these features seem like they should get pushed up into a generic framework for all SCMs like scm.eclass. Thanks, Donnie I'm already working on git.eclass. I've got some nice ideas for that one (or should I say, ideas, that I would want in it? ;-)). But I don't think, that they would benifit from a generic framework, since it's just a few lines anyway and since every scm is somewhat different, maybe it would blow up the generic thing. Regards, Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] subversion.eclass
Doug Klima schrieb: 2) ESVN_OFFLINE which disables svn up. Isn't this a bit of a hack? The point is for it to run svn up. Now I've added support in a local refactor that I had started today that if the working copy's revision matches the requested revision, that no svn up is performed. Obviously the situation when you have a live SVN ebuild would still result in an svn up, but then again live SVN ebuilds are frowned upon and if the person is trying to emerge a live SVN ebuild I would expect them to always get the latest version. What, if - the server containing the repository doesn't respond? - there is currently no connection to update but you need to remerge because of new useflags added (or similar)? In both cases with a normal merge it will die when trying to do svn up. Of course with 1) you could hack around that and specify the last revision in the repository, which btw. did a svn up, too, but this was changed today. Regards, Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: scm eclasses/ebuilds and revision logging
I did now try this for a while and it works quite good, it only has one
problem. If the package gets unmerged, for whatever reason, then the
file will be unmerged. I know, that it is possible to keep dirs, but is
it possible to keep files (without touching them manually outside portage)?
Bernd
Ryan Hill schrieb:
Bernd Steinhauser wrote:
I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)
Hope someone comes up with some good ideas. ;)
Would something like this work for you?
pkg_preinst() {
local pkgdate=$(date +%Y%m%d %H:%M:%S)
subversion_wc_info
if [[ -n ${PORT_SCMDIR} ]]; then
[[ -e ${ROOT}/${PORT_SCMDIR}/${PN}.revision ]] \
cp ${ROOT}/${PORT_SCMDIR}/${PN}.revision ${T}
echo ${pkgdate} - ${P} was merged at revision
${ESVN_WC_REVISION} \
${T}/${PN}.revision
insinto ${PORT_SCMDIR}
doins ${T}/${PN}.revision
fi
}
that's for subversion of course. set PORT_SCMDIR in make.conf.
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] scm eclasses/ebuilds and revision logging
Avuton Olrich schrieb:
On 1/11/08, Bernd Steinhauser [EMAIL PROTECTED] wrote:
Hi,
this is sth. that has been brought up in the KDE4 forums thread and on
irc. The thing is, that if you're using a live ebuild you might very
likely run into bugs, that have been introduced in a newer revision.
Now when you get in touch with upstream about that bug it might be very
useful if you can tell them, that you know, that a specific version in
the past worked. The idea was now to add the ability to the scm eclasses
to do this automatically.
So after installation then sth. like this
${CAT}/${P} merged at revision (or commit) ${REVISION}
to a file like /var/log/portage/scm.log.
Now I'm sure there are a few dirty ways to achieve this, but I wonder if
there is an easy and clean way to do this?
The problem is (I think so), that you can't just write sth. to / because
of the sandbox, so there needs to be a way to get around that, and it
should also happen after installation (post_inst).
Now if anyone wonders if this might even be useful for the distributed
scm's, I do think so. Because of course if you merge sth. from another
tree, or your ebuild repo_uri fetches from a local dir, then you might
have _other_ commit hashes than upstream, but at least you can then look
into your own repo and tell them, when that was and what happened since
then.
I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)
update-live-ebuilds[1] already stores scm x's 'cookie' (hash,
revision, whatever). CVS and TLA are the only two which don't have a
specific cookie that changes in the local directory, so sha1sum is
used on a file that is known to change with repository changes, thus
they are not a good target for this.
Cookie values and the emerging epoch are stored in a uniform manner,
in /var/db/ule/*, and since ULE is bash even a caveman could add
logging stuff to it cleanly.
I would suspect anyone who uses live ebuilds on a routine basis should
already know about ULE and be using it. Please excuse me if this
method considered 'dirty', or offtopic, it was not meant to be.
Patches and criticism welcome.
[1]http://forums.gentoo.org/viewtopic-t-518701.html
http://repo.or.cz/w/ule.git
Well, of course that would be possible, but I thought about making this
part of the ebuilds, because normally you need that kind of information
when you previously didn't think about it and imho it should be part of
the stand procedure for live ebuilds.
Bernd
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: scm eclasses/ebuilds and revision logging
Ryan Hill schrieb:
Bernd Steinhauser wrote:
I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)
Hope someone comes up with some good ideas. ;)
Would something like this work for you?
pkg_preinst() {
local pkgdate=$(date +%Y%m%d %H:%M:%S)
subversion_wc_info
if [[ -n ${PORT_SCMDIR} ]]; then
[[ -e ${ROOT}/${PORT_SCMDIR}/${PN}.revision ]] \
cp ${ROOT}/${PORT_SCMDIR}/${PN}.revision ${T}
echo ${pkgdate} - ${P} was merged at revision
${ESVN_WC_REVISION} \
${T}/${PN}.revision
insinto ${PORT_SCMDIR}
doins ${T}/${PN}.revision
fi
}
that's for subversion of course. set PORT_SCMDIR in make.conf.
This is sort of what I thought of (of course you brought it into
detail), but I didn't know if there is maybe a better way, or if there
is actually a way to do this after the installation and not in preinst.
But I guess if nobody comes up with something better this is the way to
do it.
Maybe sth. like elog, just you don't log a message to summary.log, but
you log the revision of the package.
(Meaning, that you can use elog in every phase of an ebuild.)
Bernd
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] scm eclasses/ebuilds and revision logging
Mike Frysinger schrieb: On Friday 11 January 2008, Bernd Steinhauser wrote: this is sth. reading your e-mail drove me nuts as i cant figure out what sth means. google says Sonic The Hedgehog. not sure how this applies to Gentoo (he's really fast?). http://en.wiktionary.org/wiki/something Sorry, thought that was common. ;) Bernd -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] scm eclasses/ebuilds and revision logging
Hi,
this is sth. that has been brought up in the KDE4 forums thread and on
irc. The thing is, that if you're using a live ebuild you might very
likely run into bugs, that have been introduced in a newer revision.
Now when you get in touch with upstream about that bug it might be very
useful if you can tell them, that you know, that a specific version in
the past worked. The idea was now to add the ability to the scm eclasses
to do this automatically.
So after installation then sth. like this
${CAT}/${P} merged at revision (or commit) ${REVISION}
to a file like /var/log/portage/scm.log.
Now I'm sure there are a few dirty ways to achieve this, but I wonder if
there is an easy and clean way to do this?
The problem is (I think so), that you can't just write sth. to / because
of the sandbox, so there needs to be a way to get around that, and it
should also happen after installation (post_inst).
Now if anyone wonders if this might even be useful for the distributed
scm's, I do think so. Because of course if you merge sth. from another
tree, or your ebuild repo_uri fetches from a local dir, then you might
have _other_ commit hashes than upstream, but at least you can then look
into your own repo and tell them, when that was and what happened since
then.
I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)
Hope someone comes up with some good ideas. ;)
Greetings,
Bernd
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Improving use.desc
Hi, What about sth. like this: fglrx - VIDEO_CARDS setting to build driver for fglrx video cards fglrx - Build AMD's proprietary video driver for r300-r600 video cards nv - VIDEO_CARDS setting to build driver for nv video cards nv - Open source driver for Nvidia cards, only supports 2D (I don't know what cards it supports.) nouveau - Open source driver for Nvidia cards, with 3D support (When it will make it to portage, at some time in the future. ;-)) nvidia - VIDEO_CARDS setting to build driver for nvidia video cards nvidia - Nvidia's proprietary video driver (some cards need a special version) radeon - ATI Radeon up to X1050-series (i.e. Radeon SDR/DDR, Radeon 7000-9800, and Radeon X300-X1050 are supported) radeon - Open source driver with 3D support, that supports ATI cards up to r500 chips (r600 Chips without 3D acceleration) radeonhd - New open source driver based on AMD's released documentation, with support for r500/r600 chips Generally I think, that the text VIDEO_CARDS setting to build driver for X cards really doesn't help anyone, then you could also just leave it blank, which might actually be a good idea, because that encourages people to place something good in there. Bernd -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Packages up for grabs
Gilles Dartiguelongue schrieb: - net-wireless/rt2x00 I might need this one for work, but it's not set in stone yet so if anybody has the hardware, please pick this one up. rt2x00 will be introduced in kernel 2.6.24, so that package might be deprecated then. Bernd -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Old ebuilds in bugzilla
Hi, I was searching a bit through bugzilla for some ebuilds for programs, that are not yet in portage and I found, there are a lot of programs hanging in buzilla, because no one did take them for maintenance. Now some of them are quite old (no comments/activity for 2 years) and I tried some of them and found out, that sometimes they don't even compile anymore. Now I was wondering, if there is a standard procedure for things like this; I searched the mailing list for sth. like this, but didn't find anything there. So my question is, is there some kind of standard procedure for old ebuilds that lay around bugzilla, and if not, maybe there should be one? I was thinking about something like this: - Categorize ebuild requests, so one category should contain the programs, that aren't developed anymore, one category those, that are still developed, but won't work with a current toolchain/system, and those programs, that will still work with current systems. - Add them to some kind of tracker, so some users that are up to it can try to fix them, and report that, and if it not fixable, resolve the bugs as wontfix. - Maybe make use of the vote system, so bugs with ebuilds, that are quite old and don't have votes, will be closed after something like 2 years with no activity (but that would include to tell users, that they have to vote). Maybe there are better ways handling this. But I think, there is at least a problem with the number of dead ebuilds in bugzilla, because I think, that at least those, that will still work should be picked out. Bernd -- [EMAIL PROTECTED] mailing list
