Re: [gentoo-dev] Re: Reminder: please use the latest Portage/repoman version to commit to tree
On 10/04/2010 09:13 PM, Duncan wrote: > Zac Medico posted on Mon, 04 Oct 2010 10:40:29 -0700 as excerpted: > >> On 10/04/2010 12:50 AM, Michael Haubenwallner wrote: >>> >>> On 09/30/2010 09:36 AM, Andreas K. Huettel wrote: [Portage is something] that I really need to rely on, so whatever I do, I'll keep [it] stable. (My development machine(s) are also my real-life work machines.) > >>> So - would it make sense to split repoman into its own ebuild? > >> The thing is, parts of repoman are closely coupled to portage internals. >> So, if we split it out then in practice we'd end up having to do repoman >> version bumps to correspond with portage version bumps, which would >> eliminate any practical gain that we'd get from distributing it with a >> separate ebuild. > > Accepting what you wrote at face value, we've established that there must > be a repoman version for each portage version (or rather, portage series). > > But does the inverse also hold, that for each repoman version there must > be a portage version? IOW, is there a 1:1 correspondence or can it be > 1:x, where x varies? > > So in the context of this thread, it would then be possible to release a > repoman with the new feature/warning, one-each for each current portage > series (three, now, stable, ~arch and masked-2.2, four if HEAD is also > counted). Of course this wouldn't work for repoman features that are very > closely tied to new portage features, not yet in stable portage, but it > could work for others. Each current portage series would then have at > least one repoman version, but where needed, they could "tick" separately, > simply kept series-synced with a new repoman version for each portage > series when necessary. Yeah, I supposed that would work. However, I don't see new repoman checks being being added quickly enough to make it worth the effort. If people just have a little patience then the portage with the latest repoman checks will be stabilized soon enough. > But it could also well be that while such is possible, it'd be so much > more work that it's not practical, as it would ultimately drive our ever- > patient portage devs to burn-out. =:^( I don't know. I'm simply asking. Well, I just don't see a good benefit/cost ratio here. I don't think people will be getting shiny new repoman features fast enough to make it worth the extra effort. -- Thanks, Zac
Re: [gentoo-dev] Re: .la files and their future on Gentoo
On Tue, 05 Oct 2010 04:13:04 +0200 Diego Elio Pettenò wrote: > I'm going instead to link my latest blog post on the matter where I > summarised most of the points. Why a blog post? Because so I have it > available as reference for the future together with all the others. > Don't like that? Sorry, I don't care; I'm presenting information, if > you choose to not even look at it because I serve it via HTTP rather > than a mailing list, do state so I believe one of the larger objections to you providing information via blog posts is that comments with constructive criticism or tricky questions have a mysterious habit of not showing up there. > I'll make sure to ignore any of your opinions in the future. Unfortunately for Gentoo, many of the opinions you routinely ignore happen to be useful ones. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: .la files and their future on Gentoo
Richard Freeman posted on Mon, 04 Oct 2010 11:19:29 -0400 as excerpted: > On 10/03/2010 09:26 PM, Duncan wrote: >> The problem is that "in-tree" is a reasonably bounded set of builds, >> while "out-of-tree" is unlimited. Practically speaking, I simply don't >> see how Gentoo can be concerned with "out-of-tree" in general. > > If any other distro had that attitude Gentoo (and other source-based > distros) would be the only ones that provided packages for GCC, since no > other distro requires a functioning toolchain to install packages. Interesting viewpoint. But I disagree that it is so. Rather, for binary distros, while gcc and the rest of the toolchain may not be /required/ for user-side maintenance of the distribution itself, they're certainly packages that provide a specific set of functionality. As such, they're included in general distributions where such functionality may be desired, for much the same reason KDE or LAMP are included -- they are useful enough for a wide enough segment of the userbase to justify inclusion. OTOH, more specialized distributions may not include them, because they're simply not needed for the designated target usage. In gentoo-speak, binary distributions include toolchain packages not as part of @system, but for those who wish to use them in their @world. If Gentoo were therefore to take a binary distro approach, we'd do split- packages. Much as the binary distros have package-x and package-x-dev (which I'd guess include the *.la files, BTW), we'd have package-x and package-x-la, or some such. Of course, the gentoo version of that is USE flags, FEATURES, etc. Which means we're "in violent agreement!" =:^) and brings us back to... > I like the USE flag proposal because it lets us have our cake and eat it > too. Those who don't need .la files don't get them except where > absolutely essential, and those who need and are willing to live with > tons of them can have it their way. > > Gentoo is about choice... The key-variable (whether USE flag, FEATURE, or a bit more hidden) based trigger does seem the pragmatic solution here. Flameeyes, yes, I understand your objection to it on technical grounds as unnecessary complexity. And I freely admit I'm not technically astute enough (in reality, probably few Gentoo devs are, with certain noted exceptions, of course) to debate you on the merits, there. On the technical side, AFAIAC [1] you win by stipulation. But there's more to life than being technically correct. A centralized la-file-stripper implementation seems to make sense in any case, and once it's centralized, exposing a control variable for it is little additional trouble. Given the choice between allowing for the control variable in ordered to establish the necessary consensus and getting it deployed in months, vs either continuing to debate it for years or simply steamrolling it thru without that option, whatever the technical merits, I agree with rich0, the control variable seems the /clear/ winner, here. Assuming that's the way it ultimately goes, what remains is to settle on the nature of the control variable. There are merits in something slightly hidden, but OTOH, the USE flag idea has merits of its own. It seems to me that the usual solution in similar cases is a USE flag, but masked. So count this as a vote for a masked USE flag. =:^) --- [1] AFAIAC: As Far as I am concerned: http://www.onelook.com/cgi-bin/cgiwrap/bware/dofind.cgi?word=AFAIAC -- 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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/openvpn: ChangeLog openvpn-2.1.3.ebuild
On Fri, 1 Oct 2010 20:47:38 +0530 Nirbheek Chauhan wrote: > >> for i in $( ls 2>/dev/null ); do [...] > A nice way around this is to do the following: > > ls -1 | while read i; do What pva carelessly omitted to point out was that using ls(1) is incredibly bad bash programming, which is probably why stderr is being redirected in this case, too. :) jer
[gentoo-dev] Re: Reminder: please use the latest Portage/repoman version to commit to tree
Zac Medico posted on Mon, 04 Oct 2010 10:40:29 -0700 as excerpted: > On 10/04/2010 12:50 AM, Michael Haubenwallner wrote: >> >> On 09/30/2010 09:36 AM, Andreas K. Huettel wrote: >>> [Portage is something] that I really need to rely on, >>> so whatever I do, I'll keep [it] stable. >>> >>> (My development machine(s) are also my real-life work machines.) >> So - would it make sense to split repoman into its own ebuild? > The thing is, parts of repoman are closely coupled to portage internals. > So, if we split it out then in practice we'd end up having to do repoman > version bumps to correspond with portage version bumps, which would > eliminate any practical gain that we'd get from distributing it with a > separate ebuild. Accepting what you wrote at face value, we've established that there must be a repoman version for each portage version (or rather, portage series). But does the inverse also hold, that for each repoman version there must be a portage version? IOW, is there a 1:1 correspondence or can it be 1:x, where x varies? So in the context of this thread, it would then be possible to release a repoman with the new feature/warning, one-each for each current portage series (three, now, stable, ~arch and masked-2.2, four if HEAD is also counted). Of course this wouldn't work for repoman features that are very closely tied to new portage features, not yet in stable portage, but it could work for others. Each current portage series would then have at least one repoman version, but where needed, they could "tick" separately, simply kept series-synced with a new repoman version for each portage series when necessary. But it could also well be that while such is possible, it'd be so much more work that it's not practical, as it would ultimately drive our ever- patient portage devs to burn-out. =:^( I don't know. I'm simply asking. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: .la files and their future on Gentoo
Il giorno sab, 02/10/2010 alle 19.54 +, Jorge Manuel B. S. Vicetto ha scritto: > > With that goal in mind, I'd like to ask anyone with arguments about > this > issue to present them as a reply to this thread. I'm going instead to link my latest blog post on the matter where I summarised most of the points. Why a blog post? Because so I have it available as reference for the future together with all the others. Don't like that? Sorry, I don't care; I'm presenting information, if you choose to not even look at it because I serve it via HTTP rather than a mailing list, do state so; I'll make sure to ignore any of your opinions in the future. Now, stop with the less-than-friendly remarks, the content is at http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points Also, I would like to ask again that if you're going to argue "you never know who might use them", you're going to have to actually understand _what_ the files are used for, _which_ software uses them, and come up with a use case for them, not a vague "oh there might be a project that use them". I might disagree with Nirbheek's assessment with the severity of the hit on users (or rather, on the relative severity of it compared with the alternative), but his reasoning is at least sound and based on real concerns. Things like "taking in account what isn't in the tree" (without actually having a clue on what .la files are for), looking for "alternative approaches" (to do what, exactly?), or "fixing what needs .la files" (why? if the package needs its own .la files to be around and nothing else, just leave it be!) are not concerns that I care about because they are not based on actual usefulness of .la files but on vague ideas of either fending off the finding of a solution (I don't want to know why, sincerely) or the idea that .la files are a binary situation where you shouldn't have any at all. From my point of view, the only points worth to be raised are Nirbheek's (even though I disagree, as I said), Rémi's (which I don't think he either considers showstoppers at this point) and those not-yet-spoken off by Prefix (they might support architectures where .la files are worth something). Other than that, do we really have a problem here? Nirbheek's point about stable will become moot next month; since we shouldn't revert the changes that did go to stable, we're left with two main issues here: - is it okay to drop them from stable? my personal opinion here is to side with Samuli and say "yes"; on the other hand, since by the looks of it, and the status report Zac gave us, we're going to need just one extra month before just telling users "install lafilefixer and update to stable portage 2.1.9.13", I think we can avoid doing any more of those changes till then — in stable that is; this includes both non-revbumps and stable requests of packages dropping them; - what about Rémi's 2b concern? Sincerely I have worked for a long time with static linking on my job and I don't see libtool files being so excessively necessary; the only problem comes with transitive dependencies, but most packages already take care of that; even if you do not use pkg-config, you have other means to recover it. On the other hand, I propose that if somebody have time on their hands (I sincerely don't, unless somebody's going to hire me to, and I'm dead serious), lafilefixer could be improved, and quick-stabled together with the new portage in case, so that it saves the modified metadata in the VDB. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Re: .la files and their future on Gentoo
Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto: > > That said, supporting this use case should not interfere with more > mainstream use of the distro. I like the USE flag proposal because it > lets us have our cake and eat it too. Those who don't need .la files > don't get them except where absolutely essential, and those who need > and > are willing to live with tons of them can have it their way. USE flags add complexity, and in real use cases there are near to no good reasons at all to keep .la files around. I don't want to sound like a douchebag, but can you (or anyone else supporting the USE flag notion) explain what .la files actually do? What I'm quite sure of is that about half the people who express their opinion regarding .la files have no idea what they are used for, they expect them to be some kind of magic problem-solving fairy dust. They are not. They are a legacy of older operating system and static linking notions; they are also not magical enough as they are only consumed back by libtool. And not all the packages out there use libtool to link the final application even if they were to use autotools. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] app-portage/conf-update: new maintainer needed
Hey there, like etc-update and dispatch-conf _conf-update_ seems to be one of the more central tools in Gentoo. I have the impression that it is unmaintained because... - metadata.xml says maintainer-needed, and - upstream seems to be a single _retired_ Gentoo dev, only. There is lots of smaller task you could start with: - Clean up the (rather messy) ebuild - Integrate patches from the ebuild into a new release - Fix ugly compile warnings If you are fluid in C but not Ebuilds we may find a proxy or mentor for you. Please contact us, i.e. please reply to the thread on gentoo-dev. Thanks! Sebastian
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
On 10/04/2010 12:50 AM, Michael Haubenwallner wrote: > > On 09/30/2010 09:36 AM, Andreas K. Huettel wrote: >> as I've only recently "graduated to developer", I've got a question about >> this. Diego, your request makes perfect sense to me. But, so far I always >> thought "Python, portage, and gcc are the things that I really need to rely >> on, so whatever I do, I'll keep those stable." >> >> (My development machine(s) are also my real-life work machines.) > > As I do second these concerns, another thought: > > While /portage/ is vital to our distro (not only) for end users (including > devs doing their workwork on Gentoo systems), /repoman/ isn't. > > So - would it make sense to split repoman into its own ebuild? > > /haubi/ The thing is, parts of repoman are closely coupled to portage internals. So, if we split it out then in practice we'd end up having to do repoman version bumps to correspond with portage version bumps, which would eliminate any practical gain that we'd get from distributing it with a separate ebuild. -- Thanks, Zac
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
On 10/04/2010 08:45 AM, Fabio Erculiani wrote: > Am I the only one who is waiting for a Portage 2.2 unmask on ~arch? > It's taking months if not years ;-) Well, portage-2.1.9.x is essentially the same codebase as "portage-2.2". If you look at the 2.1.9 branch, you can see that it diverges and at the following commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=efebcb2ba1ab706b2fd69521a0b0e4d1c28abe9d This commit disables features that I consider to be unstable. Rather than try to answer the question "when will all these features will be stable," I'd prefer to ask you "which features you'd most like to have stabilized" so that we can focus our efforts on getting those specific features stabilized. -- Thanks, Zac
[gentoo-dev] Last rites: net-misc/metacafe-dl
# Ricardo Mendoza (04 Oct 2010) # Dead upstream, project no longer exists and doesn't work. # Masked for removal in 30 days. net-misc/metacafe-dl
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
Am I the only one who is waiting for a Portage 2.2 unmask on ~arch? It's taking months if not years ;-) -- Fabio Erculiani
Re: [gentoo-dev] Re: .la files and their future on Gentoo
On 10/03/2010 09:26 PM, Duncan wrote: > The problem is that "in-tree" is a reasonably bounded set of builds, while > "out-of-tree" is unlimited. Practically speaking, I simply don't see how > Gentoo can be concerned with "out-of-tree" in general. If any other distro had that attitude Gentoo (and other source-based distros) would be the only ones that provided packages for GCC, since no other distro requires a functioning toolchain to install packages. Libraries don't exist just to run packaged programs - they're also needed to build new programs. So, this is a use case that needs to be considered. Probably one of the reasons that Gentoo is popular among developers is that it provides a very complete toolchain and libraries/etc. That said, supporting this use case should not interfere with more mainstream use of the distro. I like the USE flag proposal because it lets us have our cake and eat it too. Those who don't need .la files don't get them except where absolutely essential, and those who need and are willing to live with tons of them can have it their way. Gentoo is about choice... Rich
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
On 10/04/2010 03:50 AM, Michael Haubenwallner wrote: > So - would it make sense to split repoman into its own ebuild? ++ I always did wonder why the two have been part of the same project. Repoman updates could probably be stabilized more quickly with so much worry about impact on users at large. Rich
[gentoo-dev] QA last rites for dev-util/autotoolset
# Diego E. Pettenò (04 Oct 2010) # on behalf of QA team # # Ironically, it is misusing autotools (bug #255831). It was # added in 2004 and never version bumped since; autotools # have since evolved a fair amount, while this is based # still on automake 1.6. Avoid keeping it around. # # Removal on 2010-12-03 dev-util/autotoolset
Re: [gentoo-dev] .la files and their future on Gentoo
Le 04/10/2010 08:35, Michał Górny a écrit : > On Mon, 04 Oct 2010 00:00:22 +0200 > Rémi Cardona wrote: > >> #2a) pkg-config is one solution (what upstream Xorg says: "if you >> want a static libX11, use pkg-config --static"), other teams/herds >> could fix their packages' .pc files to correctly list all required >> packages for proper static linking. It's not rocket science. > > AFAIK more .pc files rather need fixing to list only direct > dependencies when '--static' is not used. pkg-config itself takes care > of the dependencies pretty well. Right, either way, .pc files usually need a little tweaking as devs rarely touch them unless something is really broken. Patching (in accordance with upstream of course) may be required. But it's definitely my preferred solution (and a cross-platform one at that!) Cheers, Rémi
Re: [gentoo-dev] .la files and their future on Gentoo
On Mon, 04 Oct 2010 00:00:22 +0200 Rémi Cardona wrote: > #2a) pkg-config is one solution (what upstream Xorg says: "if you > want a static libX11, use pkg-config --static"), other teams/herds > could fix their packages' .pc files to correctly list all required > packages for proper static linking. It's not rocket science. AFAIK more .pc files rather need fixing to list only direct dependencies when '--static' is not used. pkg-config itself takes care of the dependencies pretty well. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
On 09/30/2010 09:36 AM, Andreas K. Huettel wrote: > as I've only recently "graduated to developer", I've got a question about > this. Diego, your request makes perfect sense to me. But, so far I always > thought "Python, portage, and gcc are the things that I really need to rely > on, so whatever I do, I'll keep those stable." > > (My development machine(s) are also my real-life work machines.) As I do second these concerns, another thought: While /portage/ is vital to our distro (not only) for end users (including devs doing their workwork on Gentoo systems), /repoman/ isn't. So - would it make sense to split repoman into its own ebuild? /haubi/ -- Michael Haubenwallner Gentoo on a different level
