[gentoo-dev] app-text/dbacl is up for grabs
Steev contacted me few hours ago to tell me he won't maintain dbacl anymore and, then, it's now up for grabs. Thanks for taking care of it signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon wrote: > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote: >> Actually, since ulm pointed out in another thread that the >> council has not mandated that we support separate /usr without an >> initramfs, I am re-considering this. > > So now that the /usr-merge steamroller can not break systems through > udev, because an alternative now exists... another way must be found? > That seems rather immature. > What must be forked next to keep this working? openrc? Tend to agree, assuming it causes no additional work for package maintainers. This all started out as udev maintainers wanting to keep things simple and closer to upstream. Systems with a separate /usr breaking was a bit of a side-effect. The general direction that was chosen was to provide alternatives for those who don't want to use an initramfs and allow udev to follow upstream. Life for the udev team is easier as a result. There is no decided strategic direction at Gentoo to move everything into /usr as there is with Fedora. It just doesn't make sense to start pushing packages there. That potentially CREATES work for maintainers (bug reports, dealing with change, etc), and there is no real benefit unless we systematically apply it (moving EVERYTHING into /usr as with Fedora). Systematically moving everything isn't going to happen by just changing an eclass. If somebody can see a benefit to having things moving in the direction of /usr then by all means stick a flag in the profiles and use it to control this behavior, and then we give choice to the end-user. However, I don't really see the point. When you change the status quo it should be because it either lowers cost or produces benefit. Rich
Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On Thu, Dec 27, 2012 at 1:30 AM, Kent Fredric wrote: > There's no reason we /can't/ have a comparable process for CVS to > eliminate needless slopping of files around in pastebins/emails, both > of which are time consuming and not designed for doing exactly that. >... >(lots of descriptions of fancy tools to make cvs more bearable) If people are looking to improve Gentoo's tools it would be far more productive for them to help out with the git migration. Can I stop somebody from making gerrit-for-cvs? No. I won't even try - Gentoo is about choice. However, the fact is that git is the future, and we're probably one of the only serious FOSS projects around still using cvs (largely because it doesn't hamper us as much as it hampers everybody else). We're really not that far from having a working git implementation. Rich
[gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On Wed, 26 Dec 2012 16:42:27 + "Tony \"Chainsaw\" Vroon" wrote: > In less than two weeks, on Tuesday January the 8th, the council will meet > again. > Now is the time to prepare & raise items that you feel should be put to a > vote. > > Please reply to this e-mail with any suggested agenda items. Even if you have > raised > the issue on a mailing list before, please repeat it now to avoid it being > missed. I'd like the Council to raise the topic of using stable USE masks in gx86 tree. The issue is that Python packages have USE-conditional (PYTHON_TARGETS) dependencies upon new, unstable Python versions. Therefore, if a particular package is to be stabilized, the relevant USE flags have to be masked (or removed) in order to fulfill the dependencies on a stable system. Currently we're resolving this through using two revisions for a package, one with the relevant flags removed (going stable) and a newer one with all flags enabled. However, this is very inconvenient for us. EAPI 5 provides use.stable.mask files to solve this but those files require profiles to be EAPI 5. Therefore, in order to be able to use it we would have to actually break the update path for older portage versions completely. I have tried to raise the topic on the mailing list [1] but it mostly resulted in some people agreeing that it is an issue that should be addressed but no real ideas. I have come up with three possible solutions myself. Long story short: a) adding new profiles which will require EAPI=5 and requiring all users to migrate to them after upgrading portage. Using new use.stable.mask files in those profiles. b) adding new profiles (with current EAPIs) and requesting our unstable users to migrate to them. Masking the relevant USE flags globally and unmasking in those profiles. c) 'fixing' the use.stable.mask feature and wording it in such a way that it would apply to EAPI 5 (or 6) packages independently of profiles EAPI. I have also opened bug 447090 [2] in order to try to get some feedback on b) but nobody bothered to answer. [1]:http://thread.gmane.org/gmane.linux.gentoo.devel/81877 [2]:https://bugs.gentoo.org/show_bug.cgi?id=447090 -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
Am Donnerstag, 27. Dezember 2012, 14:37:37 schrieb Michał Górny: > > a) adding new profiles which will require EAPI=5 and requiring all > users to migrate to them after upgrading portage. Using new > use.stable.mask files in those profiles. > > b) adding new profiles (with current EAPIs) and requesting our unstable > users to migrate to them. Masking the relevant USE flags globally > and unmasking in those profiles. > > c) 'fixing' the use.stable.mask feature and wording it in such a way > that it would apply to EAPI 5 (or 6) packages independently of profiles > EAPI. > As the original proponent of the .stable.mask files, I'd recommend solution c). This is what I intended to achieve in the beginning; I accepted to place this into a new profile EAPI after I saw no chance of it going into PMS otherwise. According to PMS, profile directories may contain files not recognized by the package manager. A package manager that does not understand the stable.mask files will thus -if PMS-compliant- just ignore them. Solutions a) and b) have the big disadvantage that you will never ever be able to use the stable.mask files in the main profile directory or the base profile (since there the main profile EAPI setting will apply also in the future). Other disadvantages have also been discussed. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 07:55:38AM +, Tony "Chainsaw" Vroon wrote: > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote: > > Actually, since ulm pointed out in another thread that the > > council has not mandated that we support separate /usr without an > > initramfs, I am re-considering this. > > So now that the /usr-merge steamroller can not break systems through > udev, because an alternative now exists... another way must be found? > That seems rather immature. > What must be forked next to keep this working? openrc? Nothing must be forked. No one has said anything is happening yet. This is just a discussion. William pgpMXyuN3dwx0.pgp Description: PGP signature
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 08:00:09AM -0500, Rich Freeman wrote: > On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon > wrote: > > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote: > >> Actually, since ulm pointed out in another thread that the > >> council has not mandated that we support separate /usr without an > >> initramfs, I am re-considering this. > > > > So now that the /usr-merge steamroller can not break systems through > > udev, because an alternative now exists... another way must be found? > > That seems rather immature. > > What must be forked next to keep this working? openrc? > > Tend to agree, assuming it causes no additional work for package maintainers. As I and others have said on this list a thousdand times, moving everything to /usr never had anything to do with systemd and udev. This is a completely separate topic. The arguments for moving everything into /usr seem to be pretty strong [1], and as gregkh and others have said, it would benefit us in the longrun to do it. Given that, that is not even what I'm discussing. I am just discussing moving the libraries that we manually install into /lib* back to /usr/lib* on Linux. William [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge pgpNxjovyb3us.pgp Description: PGP signature
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs wrote: > On Thu, Dec 27, 2012 at 08:00:09AM -0500, Rich Freeman wrote: >> On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon >> wrote: >> > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote: >> >> Actually, since ulm pointed out in another thread that the >> >> council has not mandated that we support separate /usr without an >> >> initramfs, I am re-considering this. >> > >> > So now that the /usr-merge steamroller can not break systems through >> > udev, because an alternative now exists... another way must be found? >> > That seems rather immature. >> > What must be forked next to keep this working? openrc? >> >> Tend to agree, assuming it causes no additional work for package maintainers. > > As I and others have said on this list a thousdand times, moving > everything to /usr never had anything to do with systemd and udev. This > is a completely separate topic. > It has everything to do with udev if you (as the udev maintainer for Gentoo) decide to put zero effort into keeping udev working with a traditional split-/usr configuration. Although udev is only one package of many, it is a pretty damn critical one.
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 01:35:55PM -0500, Mike Gilbert wrote: > On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs wrote: > > On Thu, Dec 27, 2012 at 08:00:09AM -0500, Rich Freeman wrote: > >> On Thu, Dec 27, 2012 at 2:55 AM, Tony "Chainsaw" Vroon > >> wrote: > >> > On Wed, 2012-12-26 at 22:01 -0600, William Hubbs wrote: > >> >> Actually, since ulm pointed out in another thread that the > >> >> council has not mandated that we support separate /usr without an > >> >> initramfs, I am re-considering this. > >> > > >> > So now that the /usr-merge steamroller can not break systems through > >> > udev, because an alternative now exists... another way must be found? > >> > That seems rather immature. > >> > What must be forked next to keep this working? openrc? > >> > >> Tend to agree, assuming it causes no additional work for package > >> maintainers. > > > > As I and others have said on this list a thousdand times, moving > > everything to /usr never had anything to do with systemd and udev. This > > is a completely separate topic. > > > > It has everything to do with udev if you (as the udev maintainer for > Gentoo) decide to put zero effort into keeping udev working with a > traditional split-/usr configuration. Although udev is only one > package of many, it is a pretty damn critical one. As I said on another thread, there was a misunderstanding on my part about setting up udev. I am looking into fixing that with the next release, but I need to coordinate with systemd as well, so I thought it would be good to wait for 197 to be released, so again, this is not correct. William pgpipNCBpHwXg.pgp Description: PGP signature
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs wrote: > > As I and others have said on this list a thousdand times, moving > everything to /usr never had anything to do with systemd and udev. This > is a completely separate topic. Understood. However, the whole request to not have to support a separate /usr without an initramfs was brought up by the udev team. If udev doesn't have the need, then they should just go do what they want to do and stop asking the council to step in, as there apparently isn't anything for them to decide on. > > The arguments for moving everything into /usr seem to be pretty strong > [1], and as gregkh and others have said, it would benefit us in the longrun > to do it. > > Given that, that is not even what I'm discussing. I am just discussing > moving the libraries that we manually install into /lib* back to > /usr/lib* on Linux. I think moving everything into /usr is a good idea. However: 1. It isn't my decision to make. This is the role of the Council. 2. It doesn't make sense for every dev to just stick stuff wherever they personally feel is best. 3. Moving just a bunch of libraries to /usr and nothing else is dumb. It brings none of the benefits of the /usr move, and gets rid of all of the benefits of complying with FHS (like systems booting fine with a separate /usr - and yes I know this is already "broken" despite the fact that it works just fine for 99% of the people running in this configuration). This is one of those situations where you need to have a plan and do it right, or don't do it at all. If people want to argue for a /usr move by all means do so. If people want to beg the Council to back this, by all means do so. If people want to run for Council by all means do so. If you want to build a mechanism that gives the choice to the end user based on a profile setting or some other sensible mechanism, by all means do so. But, until the Council decides that we're really doing a coordinated /usr move, then let's leave things alone. Sticking stuff in random locations per the whim of individual maintainers will cause nothing but trouble. Rich
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 01:49:50PM -0500, Rich Freeman wrote: > On Thu, Dec 27, 2012 at 12:03 PM, William Hubbs wrote: > > > > As I and others have said on this list a thousdand times, moving > > everything to /usr never had anything to do with systemd and udev. This > > is a completely separate topic. > > Understood. However, the whole request to not have to support a > separate /usr without an initramfs was brought up by the udev team. > If udev doesn't have the need, then they should just go do what they > want to do and stop asking the council to step in, as there apparently > isn't anything for them to decide on. I wasn't actually asking the council to step in. I was just trying to have a discussion here. > > > > The arguments for moving everything into /usr seem to be pretty strong > > [1], and as gregkh and others have said, it would benefit us in the longrun > > to do it. > > > > Given that, that is not even what I'm discussing. I am just discussing > > moving the libraries that we manually install into /lib* back to > > /usr/lib* on Linux. > > I think moving everything into /usr is a good idea. However: > > 1. It isn't my decision to make. This is the role of the Council. Tell me if I am wrong here. My understanding is that this is only true if the community itself doesn't make the decision first. > 2. It doesn't make sense for every dev to just stick stuff wherever > they personally feel is best. > 3. Moving just a bunch of libraries to /usr and nothing else is dumb. > It brings none of the benefits of the /usr move, and gets rid of all > of the benefits of complying with FHS (like systems booting fine with > a separate /usr - and yes I know this is already "broken" despite the > fact that it works just fine for 99% of the people running in this > configuration). This is one of those situations where you need to > have a plan and do it right, or don't do it at all. Ok, I can agree with this. > If people want to argue for a /usr move by all means do so. If people > want to beg the Council to back this, by all means do so. If people > want to run for Council by all means do so. If you want to build a > mechanism that gives the choice to the end user based on a profile > setting or some other sensible mechanism, by all means do so. > > But, until the Council decides that we're really doing a coordinated > /usr move, then let's leave things alone. Sticking stuff in random > locations per the whim of individual maintainers will cause nothing > but trouble. There was a long thread a while back where the /usr merge was discussed in depth and there was no escalation to the council to make the decision [1]. Unless I don't remember something significant out of that thread, we agreed that even though some of us don't like the /usr merge, it is probably a good thing for us to do it in the longrun. If I were to start that thread now, I would change my introduction to not specifically mention udev, systemd and kmod, but my view still is that it will be better for us in the longrun if we do it. Maybe that is a topic for another thread though. William [1] http://archives.gentoo.org/gentoo-dev/msg_c3c5bdabbe058b08627ff04cee896af3.xml pgps9xpLHSSH9.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On Thu, 27 Dec 2012 14:37:37 +0100 Michał Górny wrote: > c) 'fixing' the use.stable.mask feature and wording it in such a way > that it would apply to EAPI 5 (or 6) packages independently of > profiles EAPI. So what EAPI would be used to parse use.stable.mask? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 2:48 PM, William Hubbs wrote: > On Thu, Dec 27, 2012 at 01:49:50PM -0500, Rich Freeman wrote: >> Understood. However, the whole request to not have to support a >> separate /usr without an initramfs was brought up by the udev team. >> If udev doesn't have the need, then they should just go do what they >> want to do and stop asking the council to step in, as there apparently >> isn't anything for them to decide on. > > I wasn't actually asking the council to step in. I was just trying to > have a discussion here. The Council WAS asked to step in: http://www.gentoo.org/proj/en/council/meeting-logs/20120403-summary.txt http://thread.gmane.org/gmane.linux.gentoo.project/1864/focus=1867 However, you are right, the udev team did not actually request this. So, if udev 180+ doesn't break anything that wasn't already broken in udev 179- then just go about your business... :) >> 1. It isn't my decision to make. This is the role of the Council. > > Tell me if I am wrong here. My understanding is that this is only true > if the community itself doesn't make the decision first. True, but I don't see any consensus on this topic. The /usr move is VERY controversial, at least within Gentoo. This really doesn't fall into the domain of any one project either - this affects the whole distro. Even if it did fall into the domain of a single project, anybody with half a brain would realize that you don't just do something like this on the initiative of a few individuals unless you want a really big mess on your hands. > If I were to start that thread now, I would change my introduction to > not specifically mention udev, systemd and kmod, but my view still is > that it will be better for us in the longrun if we do it. Maybe that is > a topic for another thread though. Agreed. There is no harm in discussing it. I'd love to see this as a supported Gentoo configuration, and perhaps even as the default. However, this should come down to a discussion of pros/cons, especially in terms of what kinds of opportunities it creates. Something I don't like about this whole debate is that it tends to come off as "I've never run an initramfs and darn it I want to keep it that way." Gentoo has always been a cutting-edge/innovative distro. We have prefix, hardened, x32, and we were among the first to support amd64. Sure, that flexibility also lets you get away without an initramfs where other distros simply cannot. However, the lack of an initramfs should not be a crutch. I could see the exact same argument unfolding 15 years ago about forcing users to have a bootloader like grub. Go bring up the suggestion that the kernel should support direct booting on lkml and I'm sure Linus will tell you to bugger_off... Rich
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, 2012-12-27 at 15:14 -0500, Rich Freeman wrote: > Go bring up the suggestion that the kernel should support direct > booting on lkml And be pointed at EFI_STUB functionality. Next? Regards, Tony V. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 3:27 PM, Tony "Chainsaw" Vroon wrote: > On Thu, 2012-12-27 at 15:14 -0500, Rich Freeman wrote: >> Go bring up the suggestion that the kernel should support direct >> booting on lkml > > And be pointed at EFI_STUB functionality. Next? I was referring to booting from a legacy BIOS - hence my comment about 15 years ago - back when this was a completely supported linux configuration.
Re: [gentoo-dev] app-text/dbacl is up for grabs
Quoting Pacho Ramos (2012-12-27 12:20:11) > Steev contacted me few hours ago to tell me he won't maintain dbacl > anymore and, then, it's now up for grabs. > > Thanks for taking care of it If nobody is interested I can take it. -- Amadeusz Żołnowski signature.asc Description: signature
[gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On 12/27/2012 05:37 AM, Michał Górny wrote: > EAPI 5 provides use.stable.mask files to solve this but those files > require profiles to be EAPI 5. Therefore, in order to be able to use it > we would have to actually break the update path for older portage > versions completely. So, adding new profiles and deprecating the old ones is considered to "break the update path for older versions"? I don't a problem with deprecating profiles and forcing users to switch. The only manual labor involved could be `emerge -1 portage && eselect profile set `. > I have tried to raise the topic on the mailing list [1] but it mostly > resulted in some people agreeing that it is an issue that should be > addressed but no real ideas. > > I have come up with three possible solutions myself. Long story short: > > a) adding new profiles which will require EAPI=5 and requiring all > users to migrate to them after upgrading portage. Using new > use.stable.mask files in those profiles. This was my plan all along, and seems perfectly reasonable to me. -- Thanks, Zac
[gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On Thu, 27 Dec 2012 19:56:47 + Ciaran McCreesh wrote: > On Thu, 27 Dec 2012 14:37:37 +0100 > Michał Górny wrote: > > c) 'fixing' the use.stable.mask feature and wording it in such a way > > that it would apply to EAPI 5 (or 6) packages independently of > > profiles EAPI. > > So what EAPI would be used to parse use.stable.mask? I'd say profiles EAPI, to be consistent. Not that it makes any difference in gx86. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On Thu, 27 Dec 2012 12:41:08 -0800 Zac Medico wrote: > On 12/27/2012 05:37 AM, Michał Górny wrote: > > EAPI 5 provides use.stable.mask files to solve this but those files > > require profiles to be EAPI 5. Therefore, in order to be able to use it > > we would have to actually break the update path for older portage > > versions completely. > > So, adding new profiles and deprecating the old ones is considered to > "break the update path for older versions"? I don't a problem with > deprecating profiles and forcing users to switch. The only manual labor > involved could be `emerge -1 portage && eselect profile set `. No, breaking the update path was about going EAPI=5 in the base profiles. But at some point I think we'd deprecate and remove the old profiles anyway. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Wednesday 26 December 2012 23:01:46 William Hubbs wrote: > On Mon, Dec 24, 2012 at 10:48:23PM +0100, Diego Elio Pettenò wrote: > > On 24/12/2012 20:08, Mike Frysinger wrote: > > > i.e. saying "we should get rid of gen_usr_ldscript and use > > > --libdir=/lib" makes absolutely no sense. it's just begging for > > > people to screw things up constantly and waste developer time for 0 > > > gain. > > > > Amen. > > Actually, since ulm pointed out in another thread that the > council has not mandated that we support separate /usr without an > initramfs, I am re-considering this. > > In linux-only ebuilds, if we install everything in /usr as gregkh and > others have suggested, we can remove this call from them. Also, for the > other ebuilds that have this call, we can eventually disable the > function on Linux systems. as mentioned in bug 417451, the ebuilds won't drop the `gen_usr_ldscript` call. we'll update the gen_usr_ldscript itself to be a no-op. that way non- linux systems continue to work, as well as linux users who want to live in the past. on the upside, i will no longer have compassion for keeping / small, so we can close all the existing bugs about "pkg foo in / is linked against lib bar in /usr" by dumping these calls. or maybe we symlink /usr/lib to /lib ? :) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thursday 27 December 2012 13:49:50 Rich Freeman wrote: > I think moving everything into /usr is a good idea. However: i don't think it's hard to support both. the majority of packages just want to relocate shared libs into / from /usr and that's easy with one line: gen_usr_ldscript -a foo put a knob into the func itself (perhaps a var set in the profile's make.defaults) and you've addressed more than 50% of the problem. very few packages actually install into /bin and /sbin, and i don't mind a USE=sep-usr flag for them (relevant since i also see that i'm maintaining most of those packages). > 3. Moving just a bunch of libraries to /usr and nothing else is dumb. > It brings none of the benefits of the /usr move sure > and gets rid of all > of the benefits of complying with FHS (like systems booting fine with > a separate /usr - and yes I know this is already "broken" despite the > fact that it works just fine for 99% of the people running in this > configuration). strictly speaking, i don't think FHS mandates sep /usr be supported. it's fairly easy to read a merged /usr setup as being FHS compliant. > But, until the Council decides that we're really doing a coordinated > /usr move, then let's leave things alone. Sticking stuff in random > locations per the whim of individual maintainers will cause nothing > but trouble. aka today's status quo -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thu, Dec 27, 2012 at 03:14:37PM -0500, Rich Freeman wrote: > Something I don't like about this whole debate is that it tends to > come off as "I've never run an initramfs and darn it I want to keep it > that way." Gentoo has always been a cutting-edge/innovative distro. > We have prefix, hardened, x32, and we were among the first to support > amd64. Sure, that flexibility also lets you get away without an > initramfs where other distros simply cannot. However, the lack of an > initramfs should not be a crutch. Rich, you just hit my concern about this debate right on the head. I feel like the nay-sayers are opposed to it because of the FHS, and the idea of critical software going in / and everything else in /usr. The attitude seems to be that has always worked, so it must continue to work into the future, with no regard to the advantages that moving everything to /usr would give us. Another concern I've heard says that we shouldn't do this on linux because gentoo *bsd doesn't do it. I don't see that as relevant because ebuilds can be smart enough to test whether they are being emerged on Linux or *BSD. William pgptEYdZoDwIs.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
Am Donnerstag, 27. Dezember 2012, 14:37:37 schrieb Michał Górny:
>
> a) adding new profiles which will require EAPI=5 and requiring all
> users to migrate to them after upgrading portage. Using new
> use.stable.mask files in those profiles.
>
OK here's one way how we could pull option a) through. After all we have some
sort of basic versioning present in the profiles (the 10.0 part that makes no
sense otherwise).
[Note: this does not cover prefix profiles, BSD and other oddities. Need
special treatment.]
1) Define a new set of profiles by copying the current ones, and replacing the
10.0 parent by a 13.0 parent. Only differences between 10.0 and 13.0:
* the EAPI, now 5,
* e.g. an additional parent profiles/base5 (for global stable mask files)
2) Deprecate the 10.0 profiles NOW by removing them from profiles.desc and
putting the new 13.0 profiles there. This has absolutely no effect on running
installations.
3) Make a news item about removal of 10.0 profiles in a year / ${TIMESCALE}.
4) One ${TIMESCALE} later, remove 10.0 profiles. This is the ugly part, and
users need to be warned and prepared properly - here everyone needs an EAPI5
capable portage.
5) Since now all existing profiles require EAPI 5, move that requirement to
the profile root directory.
Comments?
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On 12/27/2012 03:40 PM, Andreas K. Huettel wrote:
> Am Donnerstag, 27. Dezember 2012, 14:37:37 schrieb Michał Górny:
>>
>> a) adding new profiles which will require EAPI=5 and requiring all
>> users to migrate to them after upgrading portage. Using new
>> use.stable.mask files in those profiles.
>>
>
> OK here's one way how we could pull option a) through. After all we have some
> sort of basic versioning present in the profiles (the 10.0 part that makes no
> sense otherwise).
> [Note: this does not cover prefix profiles, BSD and other oddities. Need
> special treatment.]
>
> 1) Define a new set of profiles by copying the current ones, and replacing
> the
> 10.0 parent by a 13.0 parent. Only differences between 10.0 and 13.0:
> * the EAPI, now 5,
> * e.g. an additional parent profiles/base5 (for global stable mask files)
>
> 2) Deprecate the 10.0 profiles NOW by removing them from profiles.desc and
> putting the new 13.0 profiles there. This has absolutely no effect on running
> installations.
It's not strictly necessary to remove them from profiles.desc, since
repoman ignores them if they have a 'deprecated' file, and emerge warns
any users who have a deprecated profile selected.
> 3) Make a news item about removal of 10.0 profiles in a year / ${TIMESCALE}.
>
> 4) One ${TIMESCALE} later, remove 10.0 profiles. This is the ugly part, and
> users need to be warned and prepared properly - here everyone needs an EAPI5
> capable portage.
>
> 5) Since now all existing profiles require EAPI 5, move that requirement to
> the profile root directory.
>
> Comments?
>
Sounds good to me.
--
Thanks,
Zac
