[gentoo-dev] Re: grub:2 keywords
Richard Yao posted on Fri, 29 Jun 2012 17:10:31 -0400 as excerpted: > On 06/29/2012 05:04 PM, Mike Gilbert wrote: >> On Fri, Jun 29, 2012 at 4:56 PM, Richard Yao wrote: >>> On 06/29/2012 03:04 PM, Mike Gilbert wrote: On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman wrote: > On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao > wrote: >> GRUB2 does away with the conventional stage files. It also wants a >> special BIOS Boot Partition in order to function. That is where it >> stores the equivalent of the stage2 bootcode. > Now, that should make for a fun migration! Fortunately I do have a > separate boot already, and I guess I can be daring and overwrite it > in place and trust in grub2 to still find the kernel elsewhere. > > Those without a separate boot and without any free space are likely > to find this to be painful. Resizing partitions isn't exactly > risk-free... I think Richard is incorrect here; grub2 can live on any filesystem, so long as some combination of modules can access it. >>> Do you know what function the BIOS Boot Partion serves? It is >>> necessary when using GRUB2's ZFS support. I was under the impression >>> that it stored boot code. >> Based on a Google search I think "BIOS Boot Partition" is a GPT thing. >> Not relevent if you have an MBR partition table. > This is correct. I had forgotten that I switched to GPT Some brief detail to de-fuzz things slightly... 1) Existing MBR installations function much like grub1 in terms of where the core, which replaces stage-1.5, goes. Like grub1, one of two requirements must be met: 1a) Preferable: Some slack-space between the MBR and the first partition. If this exists, grub2's core gets placed here, with the MBR using an absolute address to it, much like grub1 did with its stage-1.5s except that grub2's core is assembled from individual modules at install time and is thus able to handle anything it has modules for (as long as there's slack-space enough for the stack of necessary modules), including mdraid, lvm2, etc. 1b) Fallback: If no slack-space exists between the MBR and the first partition or if it's not enough, grub2 can install its core, much as grub1 could install its stage-1.5s, into /boot. The disadvantage in both cases is that again it's accessed via absolute-address from the mbr, and if the filesystem moves it around, as journaling and COW-based filesystems sometimes do, the data can move out from under that absolute address, breaking the boot before even grub's rescue shell is available. Thus, this is STRONGLY DISCOURAGED, but it's an option for those on old systems, and it generally works as long as you're using an older /boot filesystem like fat or ext2 that's not going to move the data around. (1c: As with grub1 it's also possible to install grub to a partition instead of to the entire disk. However, this is much more strongly discouraged with grub2 than it was with grub1, I believe for much the same reasons as with 1b.) 2) BIOS-based GPT, with a dedicated BIOS partition (typically ~128 KB or so in size is fine), is definitely preferable to legacy MBR for grub2. This is because grub2 makes use of the (bare-partition, no-filesystem) dedicated BIOS partition to place its core in, something grub1 doesn't do. With no filesystem and a special partition type dedicated by GPT for this purpose, this is the strongest guarantee yet that the core will remain undisturbed at the absolute address grub placed it at, and thus at least the core rescue shell should always be available, even if something happens to /boot (which is entirely separate from the reserved BIOS partition. If a user has planned well when they setup their GPT partitioning, this reserved BIOS partition should be plenty large enough for all required modules, even for stacked devices such as exotic filesystem on lvm on mdraid. 3) For EFI-based GPT, there's another entirely separate special reserved partition for the EFI system. According to the EFI spec, this must be formatted FAT32, and should be 256 MB or so. I don't have an EFI system so have skipped much of the grub2 documentation on this so far and thus don't know a whole lot about it. Again, if a user has planned well when setting up their GPT, they may actually have both an EFI partition and a BIOS partition (as I do here), tho only one will likely be in use. But having both in the gpt layout does allow migrating the disk from a legacy BIOS system to a newer EFI system when the time comes, without re-gdisking (fdisking for gpt). Meanwhile, for those who didn't know yet, it's worth noting that with GPT there's no primary/logical partition division, they're all the same, and there's room for upto 128 partition entries in the standard GPT, tho a larger one is possible if needed. Additionally, there's two copies of the partition table and they're checksummed, making them MUCH more reliable
[gentoo-dev]
When everything else fails, read the instructions...
Re: [gentoo-dev] grub:2 keywords
On 06/29/2012 05:04 PM, Mike Gilbert wrote: > On Fri, Jun 29, 2012 at 4:56 PM, Richard Yao wrote: >> On 06/29/2012 03:04 PM, Mike Gilbert wrote: >>> On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman wrote: On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao wrote: > GRUB2 does away with the conventional stage files. It also wants a > special BIOS Boot Partition in order to function. That is where it > stores the equivalent of the stage2 bootcode. That is similar to > FreeBSD's bootloader. Now, that should make for a fun migration! Fortunately I do have a separate boot already, and I guess I can be daring and overwrite it in place and trust in grub2 to still find the kernel elsewhere. Those without a separate boot and without any free space are likely to find this to be painful. Resizing partitions isn't exactly risk-free... Rich >>> >>> I think Richard is incorrect here; grub2 can live on any filesystem, >>> so long as some combination of modules can access it. >>> >> >> Do you know what function the BIOS Boot Partion serves? It is necessary >> when using GRUB2's ZFS support. I was under the impression that it >> stored boot code. >> > > Based on a Google search I think "BIOS Boot Partition" is a GPT thing. > Not relevent if you have an MBR partition table. > This is correct. I had forgotten that I switched to GPT on my systems because ZFS partitions drives using GPT by default. Allowing people to specify the partitioning without requiring them to do it manually is on my to do list. However, those who wish to use GPT on their systems will need a BIOS Boot Partition to store the boot code. That will not apply to older systems that are switching to GRUB2 unless they also change their partition tables. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 4:56 PM, Richard Yao wrote: > On 06/29/2012 03:04 PM, Mike Gilbert wrote: >> On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman wrote: >>> On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao wrote: GRUB2 does away with the conventional stage files. It also wants a special BIOS Boot Partition in order to function. That is where it stores the equivalent of the stage2 bootcode. That is similar to FreeBSD's bootloader. >>> >>> Now, that should make for a fun migration! Fortunately I do have a >>> separate boot already, and I guess I can be daring and overwrite it in >>> place and trust in grub2 to still find the kernel elsewhere. >>> >>> Those without a separate boot and without any free space are likely to >>> find this to be painful. Resizing partitions isn't exactly >>> risk-free... >>> >>> Rich >>> >> >> I think Richard is incorrect here; grub2 can live on any filesystem, >> so long as some combination of modules can access it. >> > > Do you know what function the BIOS Boot Partion serves? It is necessary > when using GRUB2's ZFS support. I was under the impression that it > stored boot code. > Based on a Google search I think "BIOS Boot Partition" is a GPT thing. Not relevent if you have an MBR partition table.
Re: [gentoo-dev] grub:2 keywords
On 06/29/2012 03:04 PM, Mike Gilbert wrote: > On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman wrote: >> On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao wrote: >>> GRUB2 does away with the conventional stage files. It also wants a >>> special BIOS Boot Partition in order to function. That is where it >>> stores the equivalent of the stage2 bootcode. That is similar to >>> FreeBSD's bootloader. >> >> Now, that should make for a fun migration! Fortunately I do have a >> separate boot already, and I guess I can be daring and overwrite it in >> place and trust in grub2 to still find the kernel elsewhere. >> >> Those without a separate boot and without any free space are likely to >> find this to be painful. Resizing partitions isn't exactly >> risk-free... >> >> Rich >> > > I think Richard is incorrect here; grub2 can live on any filesystem, > so long as some combination of modules can access it. > Do you know what function the BIOS Boot Partion serves? It is necessary when using GRUB2's ZFS support. I was under the impression that it stored boot code. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 3:15 PM, Rich Freeman wrote: > On Fri, Jun 29, 2012 at 3:01 PM, Mike Gilbert wrote: >> 3. grub2-install calls grub2-bios-setup which installs boot.img into >> the MBR and embeds core.img into the sectors immediately after the >> MBR. > > Ok, that isn't all that unlike grub1 - that is what stage1.5 is. It > just sounds like these aren't static files that are copied out of > /boot/grub, but rather they're built on-demand from other files there. > Grub1 figures out which static stage1.5 you need based on where /boot > is. They probably went to a more dynamic model so that they can > support stuff like LVM+MD+LUKS+etc without having every permutation of > static code. I'm not sure how smart the bootloader code ends up being > - it wouldn't surprise me if at time of install the installer does all > the work and just loads a simple bootloader on the diagnostic cylinder > with just enough smarts to find /boot if it hasn't changed. Spot on. :-)
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 3:01 PM, Mike Gilbert wrote: > 3. grub2-install calls grub2-bios-setup which installs boot.img into > the MBR and embeds core.img into the sectors immediately after the > MBR. Ok, that isn't all that unlike grub1 - that is what stage1.5 is. It just sounds like these aren't static files that are copied out of /boot/grub, but rather they're built on-demand from other files there. Grub1 figures out which static stage1.5 you need based on where /boot is. They probably went to a more dynamic model so that they can support stuff like LVM+MD+LUKS+etc without having every permutation of static code. I'm not sure how smart the bootloader code ends up being - it wouldn't surprise me if at time of install the installer does all the work and just loads a simple bootloader on the diagnostic cylinder with just enough smarts to find /boot if it hasn't changed. Rich
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 3:00 PM, Rich Freeman wrote: > On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao wrote: >> GRUB2 does away with the conventional stage files. It also wants a >> special BIOS Boot Partition in order to function. That is where it >> stores the equivalent of the stage2 bootcode. That is similar to >> FreeBSD's bootloader. > > Now, that should make for a fun migration! Fortunately I do have a > separate boot already, and I guess I can be daring and overwrite it in > place and trust in grub2 to still find the kernel elsewhere. > > Those without a separate boot and without any free space are likely to > find this to be painful. Resizing partitions isn't exactly > risk-free... > > Rich > I think Richard is incorrect here; grub2 can live on any filesystem, so long as some combination of modules can access it.
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 2:38 PM, Rich Freeman wrote: > On Fri, Jun 29, 2012 at 2:29 PM, Mike Gilbert wrote: >> It does copy all of the images to /boot so that the grub shell can be >> used to install an MBR image. grub:2 no longer has an interactive >> shell and grub2-install must be used. Therefore, copying files to >> /boot in the ebuild is completely pointless. > > Does grub2-install place any stage files where they need to be, or are > they no longer needed? I haven't experimented with it yet. > > Normally grub1 needs to be able to find the stage2 file, and that has > to be on a partition the stage1.5 can read (I believe stage1.5 is in > the diagnostic cylinder - it only uses the files in /boot during > installation). grub2 eliminates the stage_1_5 files. Instead, a "core" image is built by grub2-install. Here's how it works. 1. grub2-install copies all grub modules to /boot/grub2. This can be any file system readable by GRUB. 2. grub2-install calls grub2-mkimage which combines any modules necessary to access /boot into core.img. 3. grub2-install calls grub2-bios-setup which installs boot.img into the MBR and embeds core.img into the sectors immediately after the MBR. > > I'm not sure if grub2 completely eliminates the need to have a > "normal" partition somewhere, in a situation where raid+lvm+etc are > used. You do need a filesystem that grub2 can access through some combination of modules, and an area in which to embed core.img. The grub2 manual has a pretty good explanation. http://www.gnu.org/software/grub/manual/html_node/Installing-GRUB-using-grub_002dinstall.html http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html http://www.gnu.org/software/grub/manual/html_node/Images.html
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 2:51 PM, Richard Yao wrote: > GRUB2 does away with the conventional stage files. It also wants a > special BIOS Boot Partition in order to function. That is where it > stores the equivalent of the stage2 bootcode. That is similar to > FreeBSD's bootloader. Now, that should make for a fun migration! Fortunately I do have a separate boot already, and I guess I can be daring and overwrite it in place and trust in grub2 to still find the kernel elsewhere. Those without a separate boot and without any free space are likely to find this to be painful. Resizing partitions isn't exactly risk-free... Rich
Re: [gentoo-dev] grub:2 keywords
On 06/29/2012 02:38 PM, Rich Freeman wrote: > On Fri, Jun 29, 2012 at 2:29 PM, Mike Gilbert wrote: >> It does copy all of the images to /boot so that the grub shell can be >> used to install an MBR image. grub:2 no longer has an interactive >> shell and grub2-install must be used. Therefore, copying files to >> /boot in the ebuild is completely pointless. > > Does grub2-install place any stage files where they need to be, or are > they no longer needed? I haven't experimented with it yet. > > Normally grub1 needs to be able to find the stage2 file, and that has > to be on a partition the stage1.5 can read (I believe stage1.5 is in > the diagnostic cylinder - it only uses the files in /boot during > installation). > > I'm not sure if grub2 completely eliminates the need to have a > "normal" partition somewhere, in a situation where raid+lvm+etc are > used. > > Rich > GRUB2 does away with the conventional stage files. It also wants a special BIOS Boot Partition in order to function. That is where it stores the equivalent of the stage2 bootcode. That is similar to FreeBSD's bootloader. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 2:29 PM, Mike Gilbert wrote: > It does copy all of the images to /boot so that the grub shell can be > used to install an MBR image. grub:2 no longer has an interactive > shell and grub2-install must be used. Therefore, copying files to > /boot in the ebuild is completely pointless. Does grub2-install place any stage files where they need to be, or are they no longer needed? I haven't experimented with it yet. Normally grub1 needs to be able to find the stage2 file, and that has to be on a partition the stage1.5 can read (I believe stage1.5 is in the diagnostic cylinder - it only uses the files in /boot during installation). I'm not sure if grub2 completely eliminates the need to have a "normal" partition somewhere, in a situation where raid+lvm+etc are used. Rich
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 2:08 PM, Rich Freeman wrote: > On Fri, Jun 29, 2012 at 12:11 PM, Mike Gilbert wrote: >> As far as I can tell, grub:0 only half-way updates itself; there is a >> large ewarn telling the user that they must take action to install the >> new version in the MBR. This seems a bit broken to me. > > In what way. As far as I can tell I haven't gotten a grub upgrade in > the last 5-7 years. Since it is built static on amd64 (or at least it > was when I last installed it) nothing ever breaks. Maybe if I changed > my boot partition to a different filesystem it might have issues, but > grub just strikes me as one of those aint-broke-don't-fix things. > Right. I was contradicting vapier's statement that grub:0 automatically updates itself. It doesn't. It does copy all of the images to /boot so that the grub shell can be used to install an MBR image. grub:2 no longer has an interactive shell and grub2-install must be used. Therefore, copying files to /boot in the ebuild is completely pointless.
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 12:11 PM, Mike Gilbert wrote: > As far as I can tell, grub:0 only half-way updates itself; there is a > large ewarn telling the user that they must take action to install the > new version in the MBR. This seems a bit broken to me. In what way. As far as I can tell I haven't gotten a grub upgrade in the last 5-7 years. Since it is built static on amd64 (or at least it was when I last installed it) nothing ever breaks. Maybe if I changed my boot partition to a different filesystem it might have issues, but grub just strikes me as one of those aint-broke-don't-fix things. By all means push out the new version, make docs, ewarn the user and all that. I just don't see the point in having something messing with the MBR unless it is more likely to break if we don't. Rich
Re: [gentoo-dev] Feature Request/RFC : "Elective" virtuals
> > Perhaps it would be best to tell users that if they'd like to see the > possible choices they can run ie 'qdepends -r virtual/cron' > Quite, perhaps it could be a seperate mechanism, it would just seem that for virtuals that just provide a list of alternatives, having a seperate package that gives the *choice* of one of those alternatives seems like redundant code. ( Most virtuals are simple non-exclusive ors, so the packages that satisfy them can all be installed simultaneously, however, there are a few virtuals that are inherently exclusive-ors, as all the dependents exclude each other ) Perhaps it could be an additional metafield, upon which the choice of one of several choices could be presented to the user by using a different tool. All packages which have an "alternatives" mechanism like this could then also be indexed and the user could then only enter the selection process with a separate tool which is a wrapper for portage. I'm not sure if it makes sense or not to make it as an eselect submodule that lets the user make choices and then have something else apply them, or a dedicated tool; ie: eselect alternatives list # list all the "things" that have dependents that are mutually exclusive choices eselect alternatives set cron --auto # selects vixie-cron eselect alternatives set cron cronie emerge -uvatDN @changed_alternatives Or something like that. You could drive it of course using external metadata not bundled with the virtual's themselves, the benefit being you avoid the need to trip the whole change process for virtuals and stabilisation, but the downside is of course possible desynchronisation of choice metadata with choices that are available via the virtual. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On 30 June 2012 00:13, Corentin Chary wrote: > It's already the case: > https://github.com/iksaif/euscan/blob/master/pym/euscan/handlers/cpan.py > but my mangling functions are probably broken in some cases. If > somebody with a better knowledge of CPAN versionning scheme could fix > them it would be great ! > > Thanks, The thing is there isn't a true versioning scheme for CPAN, just a defacto one agreed upon by the community. There are several versioning schemes in employ, but the mechanics of each are rather messy, and then you have some lovely fellow like pip come along and put garbage in their version, and we have to handle it manually. For the most part though, people use "sensible" versions of a very few basic varieties, and we downstream normalise these smattering of varieties into a single form to make everything nice and tidy. Its still a work in progress migrating older ebuilds to our new normalisation scheme, but its getting there. And we do have a tool that will convert /most/ CPAN versions into portage versions, which works as long as upstream are sane: dev-perl/Gentoo-PerlMod-Version Which relies on another perl module 'version.pm' ( virtual/perl-version ) which handles most the real dirty work of normalising things, and we just do a bit of post-processing of that to make it nicer for us ( mostly stripping leading 0's in digit groups, and mapping the upstream 'developer release' hints ( ie: -TRIAL or _01 components ) to the _rc suffix. If you wanted to you could call that script, or delve into the guts of it and version.pm and try understand how it works, but you could be there a while. But we're unfortunately going to *always* need a way to correct versions, because upstream occasionally produce bogus nonsense versions that don't even make sense. ( ie: making versions go backwards and expect it to work, but it does, because the cpan indexer takes whatever was most recently uploaded ... or something like that. ) -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Re: euscan GSoC project - requesting feedback
On 29 June 2012 17:32, Duncan <1i5t5.dun...@cox.net> wrote: > > EUSCAN_VERSION=0.71 > > I don't know how difficult that would be for euscan to pickup on, but > since this would have no bearing on actual package behavior, only on > euscan, I'd guess it shouldn't require going thru the formal PMS process, > tho specifying it well enough to know whether it can be a function or > must be a straight variable assignment, etc, as well as whether quotes > are required or not, would be useful, and that's normally part of the PMS > process so at least getting input from them would be useful. > > Alternatively, define some formula that can be placed in the package's > metadata.xml. That's perhaps a better functionality match (we're talking > about metadata, after all), but getting a formula that can deal with all > the corner-cases is likely to be more difficult (and take longer) than > simply specifying a variable to be defined for each ebuild that euscan > can't immediately get correct. The problem is with this approach, some devs will want to set EUSCAN_VERSION automagically using mangling $PV As it is, we *already* have something equivalent to EUSCAN_VERSION for things derived from perl-module.eclass, MODULE_VERSION= Its not 1:1 identical to the intent of EUSCAN_VERSION, MODULE_VERSION is only really required in the generation of SRC_URI , but because of this, there is a loose MODULE_VERSION <-> distfile mapping, and a much looser $PV <-> MODULE_VERSION association. Sure, its fine for MODULE_VERSION to be made by mangling $PV, but the problem is that the *reason* people mangle $PV to make MODULE_VERSION is so they don't have to update MODULE_VERSION manually when bumping the package. Adding a non-bash non-$PV-manglable field EUSCAN_VERSION field will possibly make manually incrementing this value a mandatory thing. Not to mention, if it turns out to be "wrong" on the EUSCAN index, some dev has to drop the change into the repository, do all the manifest updating and commit signing and pushing it to CVS nonsense, when really, its metadata only relevant to euscan, so its really in the wrong place to start with. Having it handled as an exception list on the euscan would be much tidier, and the path from noticing the problem to solving the problem becomes substantially shorter. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 11:32 AM, Mike Frysinger wrote: > On Friday 29 June 2012 01:59:37 Mike Gilbert wrote: >> On Fri, Jun 29, 2012 at 1:13 AM, Mike Frysinger wrote: >> > On Monday 25 June 2012 00:15:59 Mike Gilbert wrote: >> >> An official release of grub-2.00 should be coming pretty soon. I would >> >> like to keyword this for ~amd64 and ~x86 shortly after it hits the tree. >> >> I don't do much work on base system packages, so I would like some >> >> advice on how to make this as smooth as possible. >> >> >> >> My main concern is that many people probably have sys-boot/grub in >> >> @world. If grub:2 is made visible, portage will install it, and will >> >> remove grub-0.97 on the next depclean. This could be a little confusing, >> >> but should not cause any immediate damage since the copy of grub-0.97 >> >> installed in the MBR and /boot would remain intact. >> >> >> >> Is this worthy of a news item? Or I just blog about it? >> >> >> >> Anything else I need to think about here? >> > >> > do we have automatic migration/updating in place like with grub1 ? that >> > was the biggest reason i didn't unleash it for automatic installing on >> > people's systems. >> >> No, the grub2 ebuild does not automatically install the files in /boot. >> >> grub2-install performs this step, and must be run by the user. It also >> installs the MBR and embeds the core image in unused disk sectors. >> This way the MBR/core image is always kept in sync with the files in >> /boot/grub2. >> >> I don't really see a way to reliably call grub2-install from the >> ebuild, and I think this would be a bit unfriendly to the user anyway. > > grub1 doesn't seem to have a problem auto-updating itself. why is grub2 any > different ? > -mike As far as I can tell, grub:0 only half-way updates itself; there is a large ewarn telling the user that they must take action to install the new version in the MBR. This seems a bit broken to me.
Re: [gentoo-dev] grub:2 keywords
On Friday 29 June 2012 01:59:37 Mike Gilbert wrote: > On Fri, Jun 29, 2012 at 1:13 AM, Mike Frysinger wrote: > > On Monday 25 June 2012 00:15:59 Mike Gilbert wrote: > >> An official release of grub-2.00 should be coming pretty soon. I would > >> like to keyword this for ~amd64 and ~x86 shortly after it hits the tree. > >> I don't do much work on base system packages, so I would like some > >> advice on how to make this as smooth as possible. > >> > >> My main concern is that many people probably have sys-boot/grub in > >> @world. If grub:2 is made visible, portage will install it, and will > >> remove grub-0.97 on the next depclean. This could be a little confusing, > >> but should not cause any immediate damage since the copy of grub-0.97 > >> installed in the MBR and /boot would remain intact. > >> > >> Is this worthy of a news item? Or I just blog about it? > >> > >> Anything else I need to think about here? > > > > do we have automatic migration/updating in place like with grub1 ? that > > was the biggest reason i didn't unleash it for automatic installing on > > people's systems. > > No, the grub2 ebuild does not automatically install the files in /boot. > > grub2-install performs this step, and must be run by the user. It also > installs the MBR and embeds the core image in unused disk sectors. > This way the MBR/core image is always kept in sync with the files in > /boot/grub2. > > I don't really see a way to reliably call grub2-install from the > ebuild, and I think this would be a bit unfriendly to the user anyway. grub1 doesn't seem to have a problem auto-updating itself. why is grub2 any different ? -mike signature.asc Description: This is a digitally signed message part.
GLEP draf for cross-compile support in multilib profiles (was: Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5))
Brian Harring schrieb: > > You need a glep here frankly; per the norm, if you want things to move > faster, then put in time- aka, generate a patch against PMS, write a > patch for portage, etc, you get the idea. The bit re: a PMS patch is > mostly that in looking at your proposal... well, I personally don't > want to write that patch (nor do I suspect ulm/ciaran do either). As written earlier, a patch for portage exists already (just the diff between multilib and master branch of portage). Now, in addition, a GLEP draft for cross-compile support in multilib-portage. > > One thing to note; this has been posted for all of 2-3 days; that's > not exactly much time for 1) people to comment, 2) people to frankly > comprehend the quite dense description you wrote. This may be true, but as you may have seen afterwards, beside the responses to my mail about planned council asking, there have not been any further responses, so the relatively short time since my mail doesnt seem like the reason for missing responses. > > Please write a glep covering details of the implementation, > background, preferablly why this route over others. Bluntly... clue > everyone else in rather than hoping they'll just sign off on a fairly > opaque list of things. :) It'll be useful for dev education also- > which is a bit of a requirement for stuff of this sort considering > it's not going to be a magic deploy/shit works everywhere situation I > suspect. See attached GLEP draft. > > Would also be useful getting commentary from crossdev folk considering > your solution is intended to be (best I can tell) full cross > compilation support, and they've been leading that front for many, > many years. There is an important difference between my cross-compile support for multilib profiles and crossdev: My suggestion works with the default toolchain, which itself is able to cross-compile for other targets (like the amd64/multilib gcc is able to create 32bit libs), while crossdev is using a different toolchain for the targets. Of course, if someone from crossdev maintainers wants to comment, he is free to do so. -- Thomas Sachau Gentoo Linux Developer GLEP: XXX Title: Crosscompile support for multilib profiles Version: $Revision: 1.4 $ Last-Modified: $Date: 2003/07/19 12:09:20 $ Author: Thomas Sachau Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 24 Jun 2012 Post-History: 2-Jun-2003 Abstract Currently, multilib profiles like amd64 do support other targets, but there is no simple way to build packages for those seperate targets. A workaround for this issue are emul packages, which contain precompiled 32bit libs. This GLEP extends the package manager to allow the user to build packages from source for targets supported by the profile and toolchain. Motivation == There is no way to build packages for other then the default target also the profile and toolchain do support them. For amd64, there are precompiled emul packages, which only support a predefined subset of packages, are not compiled with the respect for the user USE or comiler flags and tend to become outdated due to the amount of packages they include. Specification = This GLEP will extend the functionality of package managers with a future EAPI. With this EAPI, users will be able to select additional or different targets per package by adjusting the additional USE flags. Ebuilds themselves dont have to be modified to support this. If a dependency does support the future EAPI, depending packages may require a specific target to be enabled via use dependencies. Exmaple: profile: amd64/multilib package dev-libs/a uses the future EAPI packge app-misc/b requires 32bit libs from dev-libs/a It can now define this in the dependency section as following: DEPEND="dev-libs/a[multilib_abi_x86]" Rationale = The proposal does add USE flags for each supported target ABI. This allows the user to select per package, if he wants to compile it for the default target, additionally for another target or just for another target. An alternative would have been a global variable defining this support for all packages at once. This was not done, because it would force the user to either build all (even unneeded packages) or nothing with additional or different target support without the ability to choose on a per package level. The proposel does add a USE flag called "abiwrapper" to control the behaviour for binaries. If this flag is enabled and there is a none-default target enabled, the binaries for each target are preserved and installed with their target as suffix. A symlink is created for the binary name to a wrapper, which does execute the real binary based on a set environment variable. Following alternative implementations have not been selected: * no wrapper: This would mean, that the installed binaries change, depending on the selected targets. Since some binaries have
Re: [gentoo-dev] Feature Request/RFC : "Elective" virtuals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/06/12 09:41 PM, Kent Fredric wrote: > I was doing a fresh Gentoo install today, following the manual, and > it appeared to me that the manual suggests to install a "logger" > and a "cron", and gives some defacto suggestions. > > However, the available packages that provide this facility(s) are > not overly obvious from a portage standpoint. > > The best index I can find presently for a list of things that > provide these facilities are virtual/cron , and virtual/logger , > and only then by perusing the source. > > And if you tell somebody to install "virtual/cron", you'll get the > first thing in the ||( ) list, not an elective choice of which to > install. > > It makes sense to me that there are some circumstances, where it > makes sense to, instead of simply picking the first match, present > the user with the option of one of them ( somehow ). > > ie: emerge -pv virtual/cron could, instead of the current > behaviour of installing vixie-cron,show a list with the non-chosen > alternatives: > > What we presently get is this: > > [ebuild N ] sys-process/vixie-cron-4.1-r12 USE="pam -debug > (-selinux)" 0 kB [ebuild N ] virtual/cron-0 0 kB > > Where it might be nice to instead give: > > [ebuild N ] sys-process/vixie-cron-4.1-r12 USE="pam -debug > (-selinux)" 0 kB [ebuild ? ] sys-process/cronie-1.4.8 > USE="inotify pam" ( virtual/cron ) [ebuild ? ] > sys-process/dcron-4.5 44 kB ( virtual/cron ) [ebuild ? ] > sys-process/fcron-3.0.6-r1 USE="pam -debug (-selinux)" > LINGUAS="-fr" 540 kB ( virtual/cron ) [ebuild ? ] > sys-process/bcron-0.09 57 kB ( virtual/cron ) [ebuild N ] > virtual/cron-0 0 kB > > As a way to show that vixie-cron is being chosen as the default, > but there are other things that can optionally provide that virtual > too. > > (* important: dependent children of the alternatives should not be > computed or displayed, as this will only add confusion, not to > mention headaches, as all the above crons have blockers on each > other to stop them being installed together ) > > This is the "Simplest" option I could think of that made it more > "User facing" that these virtuals exist to provide a given feature > using a mechanism of the users choice. > > You could take this further and make an interactive choice system, > which was only presented in certain conditons, ie: if the ||( ) > condition was not already satisfied, or if the users command > indicated they want to choose virtuals themselves: > > emerge --virtuals=auto # current behaviour emerge > --virtuals=pick-missing # interactive choice only if the > conditionals are not already satisfied emerge > --virtuals=pick-specified # interactive choice only for virtuals > listed on the invocation line emerge --virtuals=pick-all # > interactive choice every time > > Theres possibly other avenues I haven't thought of that might also > be useful. > > The pick interface could be something like > > virtual/cron can be provided by one of the following 1) > sys-process/vixie-cron (4.1-r12): Paul Vixie's cron daemon, a fully > featured crond implementation 2) sys-process/bcron (0.09): A new > cron system designed with secure operations in mind by Bruce > Guenter 3) sys-process/cronie (1.4.8): Cronie is a standard UNIX > daemon cron based on the original vixie-cron. 4) sys-process/dcron > (4.5): A cute little cron from Matt Dillon 5) sys-process/fcron > (3.0.6-r1): A command scheduler with extended capabilities over > cron and anacron choice[1]: > > *( list taken liberally from eix -c ) > > Then the documentation could be updated to simply tell the user > > emerge --virtuals=pick-specified virtual/cron virtual/logger > > And they could then just use the defaults ( by pressing enter ), > or choosing their favourite. > > Also, perhaps "Virtuals" is a poor name for what mechanism I am > describing. There are potentially many things that want an > elective process like this on many packages, but it seems a > mechanism more prevalent in virtuals. Especially as this facility > is mostly provided by the "USE" mechanism in most other places. > However, in VIRTUALS where you have a list of mutually exclusive > alternates, a long list of USE flags with one of them defaulted via > IUSE seems bad. Not to mention, the mechanism for displaying what > each individual USE flag will get you is a bit messy at present. ( > Being, you have to invoke some other portage command, and this > requires you finding applicable documentation for that command, to > work out how to query what each individual USE flag means , and > then run a different command for each package you want to consider > to see its description ) > > The reason for the virtual itself is so that all of the various packages that can satisfy the virtual will satisfy all the consumers (rdeps) of that virtual. It's not so much for providing a shortcut for the user; I haven't c
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On Fri, Jun 29, 2012 at 8:53 AM, Michał Górny wrote: > On Fri, 29 Jun 2012 14:07:58 +1200 > Kent Fredric wrote: > >> On 27 June 2012 19:51, Federico "fox" Scrinzi wrote: >> > The main question is: what would you like to have on this dashboard? >> > Currently (in the development version) there's the possibility to >> > login and watch/unwatch packages/categories/herds/... and see the >> > watched stuff in the account dashboard. We're planning on >> > implementing a weekly(?) custom newsletter based on the packages >> > you're watching, which features would you like? >> > >> > The project repo for the GSoC is here: >> > https://github.com/volpino/euscan >> > >> > Thanks! >> > >> >> For the most part it seems to get upstream / portage versioning right, >> but occasionally you get miss-matches for some reason. >> >> It would be nice to allow to provide some mapping mechanism that >> existed on the overlay itself to inform euscan how to map upstream >> versions to downstream ones, but implementing that would be far too >> complex I feel. >> >> Instead, it would be nice to have a mechanism in the interface to set >> a "Upstream version is" value for each package if euscan can't tell. >> >> Ie: >> >> http://euscan.iksaif.net/package/dev-perl/HTML-TreeBuilder-LibXML/ >> >> Upstream is 0.71 , portage is ( normalised ) to 0.710.0 , and these >> are in fact the same version. So in 0.710.0 , it would be nice to be >> able to set the upstream version manually to 0.71 so that euscan no >> longer reported it as outdated. > > I think we could actually handle perl pretty easily. I believe euscan > will start using CPAN API to check the package versions, and we can > embed the normalization there. It's already the case: https://github.com/iksaif/euscan/blob/master/pym/euscan/handlers/cpan.py but my mangling functions are probably broken in some cases. If somebody with a better knowledge of CPAN versionning scheme could fix them it would be great ! Thanks,
Re: [gentoo-dev] euscan GSoC project - requesting feedback
On Fri, Jun 29, 2012 at 4:07 AM, Kent Fredric wrote: > On 27 June 2012 19:51, Federico "fox" Scrinzi wrote: >> The main question is: what would you like to have on this dashboard? >> Currently (in the development version) there's the possibility to login >> and watch/unwatch packages/categories/herds/... and see the watched >> stuff in the account dashboard. We're planning on implementing a >> weekly(?) custom newsletter based on the packages you're watching, which >> features would you like? >> >> The project repo for the GSoC is here: https://github.com/volpino/euscan >> >> Thanks! >> > > For the most part it seems to get upstream / portage versioning right, > but occasionally you get miss-matches for some reason. > > It would be nice to allow to provide some mapping mechanism that > existed on the overlay itself to inform euscan how to map upstream > versions to downstream ones, but implementing that would be far too > complex I feel. > > Instead, it would be nice to have a mechanism in the interface to set > a "Upstream version is" value for each package if euscan can't tell. > > Ie: > > http://euscan.iksaif.net/package/dev-perl/HTML-TreeBuilder-LibXML/ > > Upstream is 0.71 , portage is ( normalised ) to 0.710.0 , and these > are in fact the same version. So in 0.710.0 , it would be nice to be > able to set the upstream version manually to 0.71 so that euscan no > longer reported it as outdated. > > http://euscan.iksaif.net/package/dev-perl/Authen-SASL-Cyrus-server/ > > 0.13 == 0.13-serve > > http://euscan.iksaif.net/package/dev-perl/Module-Extract-Namespaces/ > > 0.140.200_rc == 0.14_0.2 > > http://euscan.iksaif.net/package/dev-perl/Math-BaseCnv/ > http://euscan.iksaif.net/package/dev-perl/XML-Tidy/ > > 1.8 == 1.8.B59BrZ > 1.8 == 1.8.B2AMvd > > ( Upstream for those 2 packages have a versioning scheme tantamount to > intolerable cruelty. > https://rt.cpan.org/Public/Bug/Display.html?id=60275 ) > > http://euscan.iksaif.net/package/dev-perl/Perl-Critic-Moose/ > 0.999.2_rc == 0.999._002 > > http://euscan.iksaif.net/package/dev-perl/aliased/ > 0.300.100_rc == 0.30_0.1 > > http://euscan.iksaif.net/package/dev-perl/EV/ > 4.110.0 == 4.11 > > > -- > Kent > > perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, > 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" > > http://kent-fredric.fox.geek.nz > Something that could help with that: we plan to add something like debian/watch in metadata.xml. This should allow to specify a regexp to mangle versions (sed like syntax: /match/replace/). For some specific packages, we also already have specific handlers (cpan, php, pypi, etc...) which have specific version mangling functions.
Re: [gentoo-dev] grub:2 keywords
On Fri, Jun 29, 2012 at 1:59 AM, Mike Gilbert wrote: > > I don't really see a way to reliably call grub2-install from the > ebuild, and I think this would be a bit unfriendly to the user anyway. > Please don't. We don't auto-install grub during the initial install, so we have NO idea how users have set up grub1. I'd rather not try to automate the grub2 migration. For all we know they aren't even using it to boot. Interesting - it looks like I don't even have grub "installed" - the hardware on my current box has probably changed twice since I installed Gentoo on it so an install-once thing like grub that is safely tucked away in an unmounted /boot probably got out of sync. I'd think that a typical Gentoo user would want some control over their grub installation. A good guide and a news announcement of the upcoming change probably would be sufficient. Rich
