Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
> On May 22, 2018, at 4:35 PM, Michał Górnywrote: > > W dniu sob, 19.05.2018 o godzinie 18∶53 +0300, użytkownik Consus > napisał: >> Okay, this >> >>https://github.com/mgorny/portage-mgorny/issues/15 >> >> is a goddamn piece of sanity that Portage requires for a long time and >> and it worth some $20 donations. Where to send moneyz? >> > > Thanks. However, this really isn't something that deserves money. I'm > pretty sure you'll find a better use for it. I suggest that you make an amazon wishlist and let people buy you things from there. Put some books on it that would be useful for development. > > -- > Best regards, > Michał Górny > >
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu sob, 19.05.2018 o godzinie 18∶53 +0300, użytkownik Consus napisał: > Okay, this > > https://github.com/mgorny/portage-mgorny/issues/15 > > is a goddamn piece of sanity that Portage requires for a long time and > and it worth some $20 donations. Where to send moneyz? > Thanks. However, this really isn't something that deserves money. I'm pretty sure you'll find a better use for it. -- Best regards, Michał Górny
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Okay, this https://github.com/mgorny/portage-mgorny/issues/15 is a goddamn piece of sanity that Portage requires for a long time and and it worth some $20 donations. Where to send moneyz?
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/26/2018 09:48 AM, Thomas Deutschmann wrote: > On 2018-03-23 18:44, Patrick McLean wrote: >> At my (and zmedico's) employer we use Gentoo heavily (all of our servers >> run it), and have a few large internal overlays and hundreds of internal >> profiles. There are packages in upstream Gentoo that we maintain an >> internal fork of, and it would be extremely useful if we could mask the >> ::gentoo version of something so a version bump does not cause it to be >> installed instead of our forked version. > > I have the same need, but it works for me: I have several packages in > /etc/portage/package.mask directory with content like > > /::gentoo > > to make sure the package from Gentoo repository isn't used. > > But I guess you are talking about a different thing? The issue is that people are using profiles hosted in repositories other than gentoo, complete with profiles.desc entries (eselect profile supports this), and they would like to have the ability to use ::repo atoms in these profiles. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 2018-03-23 18:44, Patrick McLean wrote: > At my (and zmedico's) employer we use Gentoo heavily (all of our servers > run it), and have a few large internal overlays and hundreds of internal > profiles. There are packages in upstream Gentoo that we maintain an > internal fork of, and it would be extremely useful if we could mask the > ::gentoo version of something so a version bump does not cause it to be > installed instead of our forked version. I have the same need, but it works for me: I have several packages in /etc/portage/package.mask directory with content like /::gentoo to make sure the package from Gentoo repository isn't used. But I guess you are talking about a different thing? -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/25/2018 02:02 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 21:43:41 -0700 > Zac Medicowrote: > >> But if the majority demographic is as you describe, then they shouldn't >> be using anything having dependencies that require package.unmask or ** >> keywords changes. > > Again, they *dont*, the problem is portage makes the mistake of > thinking they do. > > This happens especially around virtuals where there is an existing > problem of portage not doing the right thing when perl-core/* exists in > some definition. > > I don't have details on hand to give you as to how this happens, > but I've seen this happen often enough around packages *I maintain* and > *I* can't explain why portage is trying to install it, only that > --auto-unmask-keep-masks=y makes the problem mysteriously go away. An issue like that involving REQUIRED_USE has been reported, and today I've created a patch that corrects the problem: https://bugs.gentoo.org/622462 > The question for me is not "auto unmask is good" vs "autounmask is > bad", autounmask is fine on its own and is very useful. > > Its the default of --autounmask-keep-masks=n that I find short on value. > > If anything, I suggest there needs to be an > --autounmask-keep-masks=conditional, or something, that narrows the > range of solutions portage will try and only attempt to unmask ** or > package.mask in the following conditions: > > - An explicitly masked package/version is explicitly requested on the command > line. > - A package is a direct dependency of of the above > - As above, but for the world file > > That is, assume the only reason for masked packages to be considered is: > - The user in some way directly requested them > - A logical consequence of the user directly requesting a masked package It's possible that bug 622462 is not the only way to trigger this problem. If anyone experiences a problem like this, then a bug report would be appreciated. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Well, in *my* opinion, in turn, having possibility to {R,}DEPEND on package from exact repo is much and much more needed functionality. Say, I have pkg2 in my repo, that depends on pkg1, which is in my repo too. Then, I (or user) add other repo having pkg1 too. Or, say, gentoo maintainers bump pkg1 to a newer version (while I'm slacking a bit). And my pkg1 is a bit different from gentoo's (let it be patchset, or, say, lua.eclass support for lua overlay). So, that changes results in random unexpected behaviour as blocks, runtime breakage and so on. And renaming all the packages to not collide with gentoo/other repos naming is, well, not an option, I think. Or, another example: I making pkg4 in my repo1, which depends on pkg3 from repo2 (where I 100% sure it fits all the requirements and the patchsets), while pkg3 in ::gentoo doesn't (and it can even have a bug about that opened for a century already). Currently, it is no way to say "only dep-pkg from that exact repo is 100% works as expected", so there is still the chance, that someday pkg4 would fail to build because suddenly pkg3 was reinstalled from another "incompatible" repo... And, honestly, current ways to resolve that issue (adding dummy-useflags, copy_here, and so on) looks as very dirty hacks.
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Sat, 24 Mar 2018 21:43:41 -0700 Zac Medicowrote: > But if the majority demographic is as you describe, then they shouldn't > be using anything having dependencies that require package.unmask or ** > keywords changes. Again, they *dont*, the problem is portage makes the mistake of thinking they do. This happens especially around virtuals where there is an existing problem of portage not doing the right thing when perl-core/* exists in some definition. I don't have details on hand to give you as to how this happens, but I've seen this happen often enough around packages *I maintain* and *I* can't explain why portage is trying to install it, only that --auto-unmask-keep-masks=y makes the problem mysteriously go away. The question for me is not "auto unmask is good" vs "autounmask is bad", autounmask is fine on its own and is very useful. Its the default of --autounmask-keep-masks=n that I find short on value. If anything, I suggest there needs to be an --autounmask-keep-masks=conditional, or something, that narrows the range of solutions portage will try and only attempt to unmask ** or package.mask in the following conditions: - An explicitly masked package/version is explicitly requested on the command line. - A package is a direct dependency of of the above - As above, but for the world file That is, assume the only reason for masked packages to be considered is: - The user in some way directly requested them - A logical consequence of the user directly requesting a masked package pgpBA7OyKTQKm.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/24/2018 07:26 PM, Kent Fredric wrote: > On Sat, 24 Mar 2018 13:44:49 -0700 > Zac Medicowrote: > >> That only happens when dependency satisfaction fails by normal means. > > And when that happens, it is better to bail and go "Uh oh, something bad", > not "oh, right, lets install something that will likely make things > worse and additional work to fix" I don't think it's possible to have defaults that satisfy everyone. My hope that the --autounmask default will be helpful to some people, and I advise people to use --autounmask=n if it's not helpful. > Its a regular occurrence that we have to tell people about this on #gentoo. Normally, it emerge shows a message like the following when it creates package.mask or ** keywords changes: NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes. >>> That default gets people using broken openssl and experimental >>> packages blindly without them ever having intended on getting into >>> experimental waters. >> >> If people can't be bothered to understand the meaning of package.mask >> and keywords changes, should they really be using Gentoo? > > And its not *entirely* true that this is the case. Toralf used to > complain portage couldn't find a resoultion and would try unmasking > insane stuff in the process of tinderboxing. > > But lo and behold, by removing the ability to unmask ** and > package.mask, he reported a significant improvement in the ability to > test. That's great. I really don't expect the default to work well in every situation. > "RTFM?" is a terrible response to "you have bad defaults that make > things break" because that default is *only* useful to people who would > consider using things that have *zero* expectation that they would work. The --autounmask behavior only triggers when a dependency is encountered that cannot be satisfied by normal means. So, it means that the user is already using masked packages, or they have expressed a desire to install a masked package. > And that is not any majority demographic of the Gentoo user base. > > Its not a useless feature, but its a feature that should only be > enabled after reading the documentation. But if the majority demographic is as you describe, then they shouldn't be using anything having dependencies that require package.unmask or ** keywords changes. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Sat, 24 Mar 2018 13:44:49 -0700 Zac Medicowrote: > That only happens when dependency satisfaction fails by normal means. And when that happens, it is better to bail and go "Uh oh, something bad", not "oh, right, lets install something that will likely make things worse and additional work to fix" Its a regular occurrence that we have to tell people about this on #gentoo. > > > That default gets people using broken openssl and experimental > > packages blindly without them ever having intended on getting into > > experimental waters. > > If people can't be bothered to understand the meaning of package.mask > and keywords changes, should they really be using Gentoo? And its not *entirely* true that this is the case. Toralf used to complain portage couldn't find a resoultion and would try unmasking insane stuff in the process of tinderboxing. But lo and behold, by removing the ability to unmask ** and package.mask, he reported a significant improvement in the ability to test. "RTFM?" is a terrible response to "you have bad defaults that make things break" because that default is *only* useful to people who would consider using things that have *zero* expectation that they would work. And that is not any majority demographic of the Gentoo user base. Its not a useless feature, but its a feature that should only be enabled after reading the documentation. pgpbFd2WgdXHb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/24/2018 01:33 PM, Kent Fredric wrote: > On Sat, 24 Mar 2018 11:27:20 -0700 > Zac Medicowrote: > >> The defaults certainly do not work perfectly in all situations. However, >> there are a vast number of situations where using --autounmask-continue >> will make appropriate package.mask changes without the need for any user >> intervention. > > Its really handy for use flags. > > Its really handy for mixed arch/~arch where it promotes arch to ~arch as > needed. > > Its really really bad however to have a default of accepting ** and > package.unmask as a primary go-to solution. That only happens when dependency satisfaction fails by normal means. > That default gets people using broken openssl and experimental packages > blindly without them ever having intended on getting into experimental > waters. If people can't be bothered to understand the meaning of package.mask and keywords changes, should they really be using Gentoo? -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Sat, 24 Mar 2018 11:27:20 -0700 Zac Medicowrote: > The defaults certainly do not work perfectly in all situations. However, > there are a vast number of situations where using --autounmask-continue > will make appropriate package.mask changes without the need for any user > intervention. Its really handy for use flags. Its really handy for mixed arch/~arch where it promotes arch to ~arch as needed. Its really really bad however to have a default of accepting ** and package.unmask as a primary go-to solution. That default gets people using broken openssl and experimental packages blindly without them ever having intended on getting into experimental waters. pgpjMgYkZB3Pa.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/24/2018 02:01 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 09:02:20 +0100 > Michał Górnywrote: > >> ...except that it is also used to say 'this is experimental version, >> unmask at will' and Portage wants to unmask stuff for you anyway. Well, >> I mean the default configuration of Portage, not mine. > > Yeah, that default I find incredibly stupid tbh. > > Auto-unmask use works nicely. Autounmask for package.mask and > accept_keywords is just madness I'd love to see stopped. > > Its right up on my list of "portage doing ultra dumb stuff? Turn this > off". > > I have it turned off in my defaults. The defaults certainly do not work perfectly in all situations. However, there are a vast number of situations where using --autounmask-continue will make appropriate package.mask changes without the need for any user intervention. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Sat, Mar 24, 2018 at 5:01 AM, Kent Fredricwrote: > On Sat, 24 Mar 2018 09:02:20 +0100 > Michał Górny wrote: > >> ...except that it is also used to say 'this is experimental version, >> unmask at will' and Portage wants to unmask stuff for you anyway. Well, >> I mean the default configuration of Portage, not mine. > > Yeah, that default I find incredibly stupid tbh. > > Auto-unmask use works nicely. Autounmask for package.mask and > accept_keywords is just madness I'd love to see stopped. > It can be useful, though obviously I review what is proposed before merging the config changes. I wouldn't put masks and keywords in the same bucket. A mask typically means that something is known to cause problems, while missing keywords typically just means that it isn't known to work yet. People running mixed-keywords will find themselves accepting keywords a fair bit. -- Rich
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Sat, 24 Mar 2018 09:02:20 +0100 Michał Górnywrote: > ...except that it is also used to say 'this is experimental version, > unmask at will' and Portage wants to unmask stuff for you anyway. Well, > I mean the default configuration of Portage, not mine. Yeah, that default I find incredibly stupid tbh. Auto-unmask use works nicely. Autounmask for package.mask and accept_keywords is just madness I'd love to see stopped. Its right up on my list of "portage doing ultra dumb stuff? Turn this off". I have it turned off in my defaults. pgpSF9IqXP_Ga.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu sob, 24.03.2018 o godzinie 20∶02 +1300, użytkownik Kent Fredric napisał: > On Fri, 23 Mar 2018 11:53:40 +0100 > Ulrich Muellerwrote: > > > Still, masking is the wrong way to express such preferences. If you > > package.mask sys-devel/gcc then you say that something is wrong with > > that package. Which I believe is not what you want to express here. > > I might have a better usecase for adding masks from overlays. > > But its more for the usecase of "there isn't something wrong with that > package", but the more frequent usecase of "Portage is stupid and so we > have masks to coerce the right behaviour" > > For example, if I had an overlay that's sole purpose was to > test/transition experimental versions of Perl, where the presumption > was that by installing said overlay, that you wished to upgrade to that > version of Perl, it might make sense to employ masks to prevent portage > doing dumb things. > > And by "Dumb things", I mean some of the common problems I see where > portage tries to solve a blocker by downgrading Perl > > Its much simpler to just author a blacklist of "Look, these are things > that are known to be a mess, don't even consider installing them, with > a nice description of why this is nonsense" > > Trying to achieve it by any other means simply tempts the problem to > reappear in another form, because everything *other* than package.mask > will have portage try to flip the USE flag to try to make it work, and > end up with people needing --backtrack=1000 and having it still not > work. > > package.mask is at least a "look, we know this is nonsense, don't even > explore this line of reasoning" blunt instrument. ...except that it is also used to say 'this is experimental version, unmask at will' and Portage wants to unmask stuff for you anyway. Well, I mean the default configuration of Portage, not mine. -- Best regards, Michał Górny
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Fri, 23 Mar 2018 11:53:40 +0100 Ulrich Muellerwrote: > Still, masking is the wrong way to express such preferences. If you > package.mask sys-devel/gcc then you say that something is wrong with > that package. Which I believe is not what you want to express here. I might have a better usecase for adding masks from overlays. But its more for the usecase of "there isn't something wrong with that package", but the more frequent usecase of "Portage is stupid and so we have masks to coerce the right behaviour" For example, if I had an overlay that's sole purpose was to test/transition experimental versions of Perl, where the presumption was that by installing said overlay, that you wished to upgrade to that version of Perl, it might make sense to employ masks to prevent portage doing dumb things. And by "Dumb things", I mean some of the common problems I see where portage tries to solve a blocker by downgrading Perl Its much simpler to just author a blacklist of "Look, these are things that are known to be a mess, don't even consider installing them, with a nice description of why this is nonsense" Trying to achieve it by any other means simply tempts the problem to reappear in another form, because everything *other* than package.mask will have portage try to flip the USE flag to try to make it work, and end up with people needing --backtrack=1000 and having it still not work. package.mask is at least a "look, we know this is nonsense, don't even explore this line of reasoning" blunt instrument. pgpN9ViSvkwJi.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Fri, 2018-03-23 at 16:23 +, Patrick Steinhardt wrote: > This wouldn't help the maintainers of overlays, though, and puts > the burden on the user. One scenario where masks maintained in > overlays would be useful is the musl overlay, which carries > patches to various packages to have them compile with musl libc. > Obviously, I always want to use packages provided by the musl > overlay in case the same package from the Gentoo tree has build > failures. Even if the Gentoo-provided package gets updated, I'll > still want to use the older version from the musl tree, as the > build errors are likely to still exist. > > If overlays were able to ignore packages from other repositories, > the musl overlay could simply mask out packages from the Gentoo > repository which are known to not compile on musl-based systems. > Like this, the user does not have to maintain these masks > manually, but they are already managed at a central place and > updated with the musl repository. > > Patrick It's currently possible to do with a sort-of-automated script in /etc/portage/repo.postsync.d i asked[1] ::musl about that and they do not want that. the script provided the issue is just an example, it should check which repo was just synced, also it does not care about versions, it just masks the versionless atom, there are no any sanity checks. it's just proof of concept. But I find it useful on my underpowered APU system which runs musl. I just want to avoid build failures, as each build takes a LOT of time. I would not run that on a workstation, I'd better bump instead and port the patches/ebuilds. running ::musl is an active commitment, and it often requires intervention and those should be contributed back if possible. [1]https://github.com/gentoo/musl/issues/110 -- Georgy
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 2018-03-23 06:27 AM, Rich Freeman wrote: > On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Muellerwrote: >>> On Fri, 23 Mar 2018, Roy Bamford wrote: >> >>> games-emulation/sdlmame is masked. I have a higher version in my >>> overlay than the one in the tree and it gets masked too. >>> Its not a problem to me as I know how to manage it. Its just untidy. >> >> You still don't need a repository specific mask for this. Version >> specific masking and unmasking is entirely sufficient to express that >> the higher version is fine. >> > > It sounds to me that one of the intended behaviors is to tell portage > that for a particular package we want to ignore a particular > repository entirely. Suppose for example an overlay contains > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want > portage to stick with foo-3 from the overlay. However, if the overlay > adds foo-4, or foo-4.1 we want this installed. A version mask would > not really cover this use case. > > IMO this sounds like a useful feature. Having it in profiles could > probably also be useful in some testing scenarios, such as when making > changes to a large number of packages that are already in the main > tree (think something analogous to a feature branch in git, where the > master branch continues to advance).> > Perhaps I'm misunderstanding the intent here, but I would suggest that > we describe the end goal in emails like these otherwise people focus > on the implementation details first. > Having the ability to specify a repository in atoms in profile is very useful to people who have large overlays and make heavy use of profiles. At my (and zmedico's) employer we use Gentoo heavily (all of our servers run it), and have a few large internal overlays and hundreds of internal profiles. There are packages in upstream Gentoo that we maintain an internal fork of, and it would be extremely useful if we could mask the ::gentoo version of something so a version bump does not cause it to be installed instead of our forked version. To address ulm's comments, we want our internal fork to satisfy dependencies in ::gentoo for the package without having to fork dozens of ebuilds. Generally the forks are just for minor changes that do not break dependency compatibility, but do something that we need for whatever reason. In case there are questions about why we have hundreds of profiles, we use profile to define machine roles. Each internal machine type or role has a profile in one of our internal repositories. This allows us to manipulate USE flags, packages etc in each machine type with a fair bit of fine-grained control. Adding repository support to profile atoms will give us even more control, and having fine grained control over what we have on our servers is the main reason we run Gentoo.
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Fri, Mar 23, 2018 at 03:25:12PM +0100, Arve Barsnes wrote: > On 23 March 2018 at 14:27, Rich Freemanwrote: > > It sounds to me that one of the intended behaviors is to tell portage > > that for a particular package we want to ignore a particular > > repository entirely. Suppose for example an overlay contains > > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want > > portage to stick with foo-3 from the overlay. However, if the overlay > > adds foo-4, or foo-4.1 we want this installed. A version mask would > > not really cover this use case. > > > > IMO this sounds like a useful feature. Having it in profiles could > > probably also be useful in some testing scenarios, such as when making > > changes to a large number of packages that are already in the main > > tree (think something analogous to a feature branch in git, where the > > master branch continues to advance). > > Unless I'm misunderstanding, this is possible already in package.mask? > If the mask is not permanent (for testing, as you mention), would > there be any benefit in having it in profile instead? > > Putting misc/foo::gentoo in package.mask works fine either way. > Probably > I use this for the opposite scenario, I have */*::overlay in > package.mask, and unmask only a particular package in package.unmask, > to avoid bringing in a lot of overlay packages without having a > particular need. > > Arve This wouldn't help the maintainers of overlays, though, and puts the burden on the user. One scenario where masks maintained in overlays would be useful is the musl overlay, which carries patches to various packages to have them compile with musl libc. Obviously, I always want to use packages provided by the musl overlay in case the same package from the Gentoo tree has build failures. Even if the Gentoo-provided package gets updated, I'll still want to use the older version from the musl tree, as the build errors are likely to still exist. If overlays were able to ignore packages from other repositories, the musl overlay could simply mask out packages from the Gentoo repository which are known to not compile on musl-based systems. Like this, the user does not have to maintain these masks manually, but they are already managed at a central place and updated with the musl repository. Patrick signature.asc Description: PGP signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Hi guys, sys-devel/gcc::repos is only an example but from my side it is a real example. Currently, Sabayon use our gcc ebuild so it is needed mask gentoo version for rebuild sabayon-stage3 and now it is only possible (like other packages) through file (from sabayon side): /etc/portage/package.mask/00-sabayon.package.mask My idea is permit to define this mask rules under sabayon overlay as profile and/or as targets. Interesting idea is opposite scenario propose by Barsnes about block overlay packages. Thank you to all for feedback about this proposal. G. On Fri, 2018-03-23 at 15:25 +0100, Arve Barsnes wrote: > On 23 March 2018 at 14:27, Rich Freemanwrote: > > It sounds to me that one of the intended behaviors is to tell > > portage > > that for a particular package we want to ignore a particular > > repository entirely. Suppose for example an overlay contains > > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we > > want > > portage to stick with foo-3 from the overlay. However, if the > > overlay > > adds foo-4, or foo-4.1 we want this installed. A version mask > > would > > not really cover this use case. > > > > IMO this sounds like a useful feature. Having it in profiles could > > probably also be useful in some testing scenarios, such as when > > making > > changes to a large number of packages that are already in the main > > tree (think something analogous to a feature branch in git, where > > the > > master branch continues to advance). > > Unless I'm misunderstanding, this is possible already in > package.mask? > If the mask is not permanent (for testing, as you mention), would > there be any benefit in having it in profile instead? > > Putting misc/foo::gentoo in package.mask works fine either way. > Probably > I use this for the opposite scenario, I have */*::overlay in > package.mask, and unmask only a particular package in package.unmask, > to avoid bringing in a lot of overlay packages without having a > particular need. > > Arve >
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 23 March 2018 at 14:27, Rich Freemanwrote: > It sounds to me that one of the intended behaviors is to tell portage > that for a particular package we want to ignore a particular > repository entirely. Suppose for example an overlay contains > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want > portage to stick with foo-3 from the overlay. However, if the overlay > adds foo-4, or foo-4.1 we want this installed. A version mask would > not really cover this use case. > > IMO this sounds like a useful feature. Having it in profiles could > probably also be useful in some testing scenarios, such as when making > changes to a large number of packages that are already in the main > tree (think something analogous to a feature branch in git, where the > master branch continues to advance). Unless I'm misunderstanding, this is possible already in package.mask? If the mask is not permanent (for testing, as you mention), would there be any benefit in having it in profile instead? Putting misc/foo::gentoo in package.mask works fine either way. Probably
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Muellerwrote: >> On Fri, 23 Mar 2018, Roy Bamford wrote: > >> games-emulation/sdlmame is masked. I have a higher version in my >> overlay than the one in the tree and it gets masked too. >> Its not a problem to me as I know how to manage it. Its just untidy. > > You still don't need a repository specific mask for this. Version > specific masking and unmasking is entirely sufficient to express that > the higher version is fine. > I think it would be best to step back from terms like "masking" and focus more on the intended behavior. It sounds to me that one of the intended behaviors is to tell portage that for a particular package we want to ignore a particular repository entirely. Suppose for example an overlay contains misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want portage to stick with foo-3 from the overlay. However, if the overlay adds foo-4, or foo-4.1 we want this installed. A version mask would not really cover this use case. IMO this sounds like a useful feature. Having it in profiles could probably also be useful in some testing scenarios, such as when making changes to a large number of packages that are already in the main tree (think something analogous to a feature branch in git, where the master branch continues to advance). Perhaps I'm misunderstanding the intent here, but I would suggest that we describe the end goal in emails like these otherwise people focus on the implementation details first. -- Rich
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 23:06 Thu 22 Mar, Michał Górny wrote: > No. Just a few general ideas. It's Portage, so I don't expect anything > major to be able to happen. Is it possible to slowly migrate parts of sys-apps/portage to portage-utils? I really like portage-utils's approach to make things easier and modular. Also it's damn fast.
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
> On Fri, 23 Mar 2018, Roy Bamford wrote: > games-emulation/sdlmame is masked. I have a higher version in my > overlay than the one in the tree and it gets masked too. > Its not a problem to me as I know how to manage it. Its just untidy. You still don't need a repository specific mask for this. Version specific masking and unmasking is entirely sufficient to express that the higher version is fine. Ulrich pgp0qlHpHeusz.pgp Description: PGP signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
> On Fri, 23 Mar 2018, Francesco Riosa wrote: > Il 23/03/2018 10:48, Ulrich Mueller ha scritto: >> Conceptually that makes no sense. sys-devel/gcc is the name of an >> upstream package, so what does it even mean to mask it in one >> repository but not in another? If it's the same package, then it >> should behave in the same way, regardless of the repository its >> ebuild it hosted in (or the package being installed, in which case >> it is no longer in an ebuild repository). >> If it is a different package however, then it should have a >> different name. > Sorry to say it bluntly but this make no sense at all, even changing > a USE flag make the package behave wildly differently. Right, So you want USE dependencies, which we have. Nothing stops a package in an overlay from having additional USE flags. > Once we agree that an upstream (complex enough) package may have > different incarnations two ebuilds from different maintainers may > please differently the user. Still, masking is the wrong way to express such preferences. If you package.mask sys-devel/gcc then you say that something is wrong with that package. Which I believe is not what you want to express here. Ulrich pgpInHKd1i4Yn.pgp Description: PGP signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 2018.03.23 09:48, Ulrich Mueller wrote: > > On Thu, 22 Mar 2018, Geaaru wrote: > > > for both portage and your fork I think that could be interesting add > > an extension to PMS for define inside profiles or targets masking of > > packages of a particular repslository. Currently PMS doesn't permit > > this but have this feature could be help users to define our > > profiles under overlays. > > > Something like this: > > > sys-devel/gcc::gentoo > > Conceptually that makes no sense. sys-devel/gcc is the name of an > upstream package, so what does it even mean to mask it in one > repository but not in another? If it's the same package, then it > should behave in the same way, regardless of the repository its ebuild > it hosted in (or the package being installed, in which case it is no > longer in an ebuild repository). > > If it is a different package however, then it should have a different > name. > > Ulrich > Ulrich, That has just irritated me. The use case is sdlmame. !!! The following installed packages are masked: - games-emulation/sdlmame-0.195::Pi_aarch64 (masked by: package.mask) /usr/portage/profiles/package.mask: # Pacho Ramos(18 Mar 2018) # Fails to build (#634662), version bump long time pending (#596162). # Removal in a month. games-emulation/sdlmame is masked. I have a higher version in my overlay than the one in the tree and it gets masked too. Its not a problem to me as I know how to manage it. Its just untidy. With apologies to Pacho for citing his name in the worked example. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpTpwKGF0FbM.pgp Description: PGP signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
The dlang repository offers a gcc ebuild that adds the patchset to build the gdc. It's behind a USE-Flag. Still it is exactly the same as sys-devel/gcc::gentoo besides the additional feature. But I don't think the dlang repo should mask gcc::gentoo. 2018-03-23 12:18 GMT+02:00 Francesco Riosa: > > > Il 23/03/2018 10:48, Ulrich Mueller ha scritto: > >> On Thu, 22 Mar 2018, Geaaru wrote: > >> for both portage and your fork I think that could be interesting add > >> an extension to PMS for define inside profiles or targets masking of > >> packages of a particular repslository. Currently PMS doesn't permit > >> this but have this feature could be help users to define our > >> profiles under overlays. > >> Something like this: > >> sys-devel/gcc::gentoo > > Conceptually that makes no sense. sys-devel/gcc is the name of an > > upstream package, so what does it even mean to mask it in one > > repository but not in another? If it's the same package, then it > > should behave in the same way, regardless of the repository its ebuild > > it hosted in (or the package being installed, in which case it is no > > longer in an ebuild repository). > > > > If it is a different package however, then it should have a different > > name. > Sorry to say it bluntly but this make no sense at all, even changing a > USE flag make the package behave wildly differently. > Once we agree that an upstream (complex enough) package may have > different incarnations two ebuilds from different maintainers may please > differently the user. > I'm not sure this choice belong to profiles but not because same > upstream correspond to same files on filesystem. > > > > > Ulrich > > >
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Il 23/03/2018 10:48, Ulrich Mueller ha scritto: >> On Thu, 22 Mar 2018, Geaaru wrote: >> for both portage and your fork I think that could be interesting add >> an extension to PMS for define inside profiles or targets masking of >> packages of a particular repslository. Currently PMS doesn't permit >> this but have this feature could be help users to define our >> profiles under overlays. >> Something like this: >> sys-devel/gcc::gentoo > Conceptually that makes no sense. sys-devel/gcc is the name of an > upstream package, so what does it even mean to mask it in one > repository but not in another? If it's the same package, then it > should behave in the same way, regardless of the repository its ebuild > it hosted in (or the package being installed, in which case it is no > longer in an ebuild repository). > > If it is a different package however, then it should have a different > name. Sorry to say it bluntly but this make no sense at all, even changing a USE flag make the package behave wildly differently. Once we agree that an upstream (complex enough) package may have different incarnations two ebuilds from different maintainers may please differently the user. I'm not sure this choice belong to profiles but not because same upstream correspond to same files on filesystem. > > Ulrich signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
> On Thu, 22 Mar 2018, Geaaru wrote: > for both portage and your fork I think that could be interesting add > an extension to PMS for define inside profiles or targets masking of > packages of a particular repslository. Currently PMS doesn't permit > this but have this feature could be help users to define our > profiles under overlays. > Something like this: > sys-devel/gcc::gentoo Conceptually that makes no sense. sys-devel/gcc is the name of an upstream package, so what does it even mean to mask it in one repository but not in another? If it's the same package, then it should behave in the same way, regardless of the repository its ebuild it hosted in (or the package being installed, in which case it is no longer in an ebuild repository). If it is a different package however, then it should have a different name. Ulrich pgp8_IjlLGC_7.pgp Description: PGP signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu czw, 22.03.2018 o godzinie 22∶52 +, użytkownik Geaaru napisał: > Hi, > > a bit out of topic (sorry in advance) but connect to eventually new portage > feature... > > for both portage and your fork I think that could be interesting add an > extension to PMS for define inside profiles or targets masking of packages > of a particular repslository. Currently PMS doesn't permit this but have > this feature could be help users to define our profiles under overlays. > > Something like this: > > sys-devel/gcc::gentoo > > Currently this is permitted only under /etc/portage but for distro based of > gentoo or others use cases share our profiles directly under overlay could > permit an easy and elegant way to share our customizations. > > Unlucky this break specifications but I think that could be a fine new > feature. > > wdyt? Nope. Diverging from the specification is entirely against the goal of this fork. However, if mainline Portage supports that in non-spec- breaking fashion, I'm going to merge it. -- Best regards, Michał Górny
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu pią, 23.03.2018 o godzinie 01∶01 +, użytkownik Herb Miller Jr. napisał: > On 03/22/2018 04:17 PM, James Le Cuirot wrote: > > On Thu, 22 Mar 2018 20:03:46 +0100 > > Michał Górnywrote: > > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > > I have finally decided to fork Portage. My little fork uses technical > > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > > and aims to focus on cleaning up code and adding useful features with > > > less concern for infinite bug-by-bug compatibility. > > > > I hope you will continue with our efforts to drive regular Portage > > forwards too. It's been a long road but also very productive. > > > > I notice that your fork cannot be installed at the same time as regular > > Portage. I think this will really hinder any interest in it. As > > Gentoo developers, we obviously have to make sure things work with the > > official package manager and that goes for you too. Would it be > > possible for them to coexist? I'm not saying I'll try it though, just > > making a suggestion. :) > > > > Seems to also be blocked by other management tools such as perl-cleaner > and haskell-updater. I'd love to take it for a spin if you have any > suggestions on how to navigate the blocks. > > https://paste.pound-python.org/show/VxWWAGW9PpPCS3L4Q6Z3/ > The instructions covered that. You need to upgrade those packages to -r1. -- Best regards, Michał Górny
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/22/2018 04:17 PM, James Le Cuirot wrote: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górnywrote: > >> After 2+ years of repeating disagreements with Portage maintainer(s) >> I have finally decided to fork Portage. My little fork uses technical >> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), >> and aims to focus on cleaning up code and adding useful features with >> less concern for infinite bug-by-bug compatibility. > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) > Seems to also be blocked by other management tools such as perl-cleaner and haskell-updater. I'd love to take it for a spin if you have any suggestions on how to navigate the blocks. https://paste.pound-python.org/show/VxWWAGW9PpPCS3L4Q6Z3/ Herb Miller Jr.
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/22/2018 03:52 PM, Geaaru wrote: > Hi, > > a bit out of topic (sorry in advance) but connect to eventually new > portage feature... > > for both portage and your fork I think that could be interesting add an > extension to PMS for define inside profiles or targets masking of > packages of a particular repslository. Currently PMS doesn't permit this > but have this feature could be help users to define our profiles under > overlays. > > Something like this: > > sys-devel/gcc::gentoo > > Currently this is permitted only under /etc/portage but for distro based > of gentoo or others use cases share our profiles directly under overlay > could permit an easy and elegant way to share our customizations. > > Unlucky this break specifications but I think that could be a fine new > feature. > > wdyt? > > My cent. > > G. Bug filed: https://bugs.gentoo.org/651208 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Hi, a bit out of topic (sorry in advance) but connect to eventually new portage feature... for both portage and your fork I think that could be interesting add an extension to PMS for define inside profiles or targets masking of packages of a particular repslository. Currently PMS doesn't permit this but have this feature could be help users to define our profiles under overlays. Something like this: sys-devel/gcc::gentoo Currently this is permitted only under /etc/portage but for distro based of gentoo or others use cases share our profiles directly under overlay could permit an easy and elegant way to share our customizations. Unlucky this break specifications but I think that could be a fine new feature. wdyt? My cent. G. On Thu, Mar 22, 2018, 23:06 Michał Górnywrote: > W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus > napisał: > > On 20:03 Thu 22 Mar, Michał Górny wrote: > > > Hello, everyone. > > > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > > I have finally decided to fork Portage. My little fork uses technical > > > name of 'portage[mgorny]' [1] (to distinguish it from mainline > Portage), > > > and aims to focus on cleaning up code and adding useful features with > > > less concern for infinite bug-by-bug compatibility. > > > > > > Detailed rationale in README [2]. > > > > Do you have any roadmap? > > > > No. Just a few general ideas. It's Portage, so I don't expect anything > major to be able to happen. > > -- > Best regards, > Michał Górny > > >
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus napisał: > On 20:03 Thu 22 Mar, Michał Górny wrote: > > Hello, everyone. > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > I have finally decided to fork Portage. My little fork uses technical > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > and aims to focus on cleaning up code and adding useful features with > > less concern for infinite bug-by-bug compatibility. > > > > Detailed rationale in README [2]. > > Do you have any roadmap? > No. Just a few general ideas. It's Portage, so I don't expect anything major to be able to happen. -- Best regards, Michał Górny
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 20:03 Thu 22 Mar, Michał Górny wrote: > Hello, everyone. > > After 2+ years of repeating disagreements with Portage maintainer(s) > I have finally decided to fork Portage. My little fork uses technical > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > and aims to focus on cleaning up code and adding useful features with > less concern for infinite bug-by-bug compatibility. > > Detailed rationale in README [2]. Do you have any roadmap?
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On 03/22/2018 01:17 PM, James Le Cuirot wrote: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górnywrote: > >> After 2+ years of repeating disagreements with Portage maintainer(s) >> I have finally decided to fork Portage. My little fork uses technical >> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), >> and aims to focus on cleaning up code and adding useful features with >> less concern for infinite bug-by-bug compatibility. > > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) > You can probably use the PATH/PYTHONPATH approach described here as long as support for that has not been eliminated: https://wiki.gentoo.org/wiki/Project:Portage#Testing_Portage -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
W dniu czw, 22.03.2018 o godzinie 20∶17 +, użytkownik James Le Cuirot napisał: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górnywrote: > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > I have finally decided to fork Portage. My little fork uses technical > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > and aims to focus on cleaning up code and adding useful features with > > less concern for infinite bug-by-bug compatibility. > > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. Making them co-installable would require creating divergent packages and eventually making a huge mess of almost-identical-but-different Python modules. It's not worth the effort, especially that the two projects are not that divergent. > As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) As Gentoo developers, we have have to make sure things work with *all* package managers. That's why we have standards and policies. Unlike mainline Portage, portage[mgorny] follows those policies strictly and therefore any ebuild that works with it should also work with mainline Portage. -- Best regards, Michał Górny
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Thu, 22 Mar 2018 20:03:46 +0100 Michał Górnywrote: > After 2+ years of repeating disagreements with Portage maintainer(s) > I have finally decided to fork Portage. My little fork uses technical > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > and aims to focus on cleaning up code and adding useful features with > less concern for infinite bug-by-bug compatibility. I hope you will continue with our efforts to drive regular Portage forwards too. It's been a long road but also very productive. I notice that your fork cannot be installed at the same time as regular Portage. I think this will really hinder any interest in it. As Gentoo developers, we obviously have to make sure things work with the official package manager and that goes for you too. Would it be possible for them to coexist? I'm not saying I'll try it though, just making a suggestion. :) -- James Le Cuirot (chewi) Gentoo Linux Developer pgps9_fhr_B36.pgp Description: OpenPGP digital signature
[gentoo-dev] New Portage fork: sys-apps/portage-mgorny
Hello, everyone. After 2+ years of repeating disagreements with Portage maintainer(s) I have finally decided to fork Portage. My little fork uses technical name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), and aims to focus on cleaning up code and adding useful features with less concern for infinite bug-by-bug compatibility. Detailed rationale in README [2]. Before installing - This is a bleeding-edge, strictness-first fork of Portage. It is intended for developers and power users mostly. Things will break. You will eventually be asked to remove files deprecated 5+ years ago. Developer mistakes will harm you (but someone needs to find them and report them!) Dynamic dependencies are off by default (following Council decision from 3.5yr ago). If you haven't rebuilt your system recently, you may need to use '--changed-deps' once. Afterwards, things should work fine unless developers screw up, and then you should report bugs. Only ~arch version at the moment. Installing -- To switch to my fork of Portage, just: emerge -vn sys-apps/portage-mgorny Note that you may need to: emerge --deselect sys-apps/portage app-portage/repoman (repoman is integrated back into Portage) You may also need to upgrade all revdeps of Portage since the newest versions were bumped with updated dependencies. Please note that due to misdesign, Portage will abort upon having to unmerge itself on first install. However, it is a harmless failure and portage[mgorny] will be installed already at the point, so upon restarting it will just finish cleaning up. Merge plan -- I do intend to regularly merge from mainline Portage, and preserve reasonable compatibility (especially in terms of API). I also plan to keep reasonably good commit quality as to make it easier for Portage developers to merge back. However, this is not my primary concern. Releases I plan to make frequent releases. I'm planning to version the releases by sequential values of fourth version component from the last Portage release. For example, since the last Portage release is 2.3.24, I have just released portage-mgorny-2.3.24.1, the next release will be 2.3.24.2, etc. until Portage 2.3.25 is released. The releases are made against *git HEAD* and not respective Portage versions, i.e. 2.3.24.1 is [2.3.24 + changes in mainline + my changes]. The matching versions are mostly meant to make >= deps easier, i.e. you can reasonably assume portage-mgorny-2.3.24* will have all the new APIs of portage-2.3.24. The release notes [3] list any major changes I make. They do not list the respective changes in mainline Portage, sorry. Bugs, features and requests --- I'm open to your feedback, including things that were rejected by mainline Portage team. For best efficiency, please report bugs on GitHub [4] and/or open pull requests [5]. Enjoy! [1]:https://github.com/mgorny/portage [2]:https://github.com/mgorny/portage/blob/master/README [3]:https://github.com/mgorny/portage/releases [4]:https://github.com/mgorny/portage/issues [5]:https://github.com/mgorny/portage/pulls -- Best regards, Michał Górny