Hi, Sorry for my delay answering to you, i was a bit busy lately.
For "pushing the mask rule inside the meta" i actually don't know if that is possible, i never tried it, all that i know is that there are files under the /etc/entropy/packages/ directory that are used and processed from the entropy server, from what i can see this includes also the possibility to execute code on client side since doesn't seem to be documented. I wouldn't use slots in that way because then, when in future you might want to upgrade your machine massively it could became quite painful and probably you will write tricky ebuilds to keep going(and, a lot of mantainance needed) . What i would suggest is to create a package inside your repository that install the masks files and pulls also the required dependencies (or in two separate packages). Then, as an option you can trigger client-side actions on equo update or upgrade (search in /etc/entropy/packages/* files the comments wich are refeered to server-side) to install that meta-package. To build them, you might want instead a separate /etc/portage directory where you control the versions of the packages to install on the machine ( https://github.com/Sabayon/build contains all the configurations needed to build the packages in Entropy) . In this way people could choose between software in slots (not precluding this possibility in the future if you might need it) and you obtain more fine-grained control. And of course, this has the cost that you are going to provide a different version of some packages between you and Sabayon repositories. To help you mantain that in theory you could write a script that create the ebuild with the masked packages list against your requirements. To try to be as close as Sabayon's build files,i can suggest also to fork the official repository and try to put automatically on it's head your changes (this can be automatized too). You can also of course use the SLOT approach, but still you will probably end to have a different portage directory. Anyway, i think that you can tweak stuff using that file /etc/entropy/packages/packages.db.post_update.sh.example, but i'm not really sure and i never tried it. Maybe Fabio can shed some light on this. >> I think that with initiative of support Sabayon server edition, add support to an Openstack ready platform could be very powerful. WDYF ? That's exactly the point! Providing a binary rolling-release distribution with all the cloud tools was also one of my point in doing the Server Edition and sounds so cool. Of course, this probably involves to have a separate Entropy tree and we can finally start to think to provide different use flags that maybe could fit your needs also better. I personally want to see that as a project under the Sabayon umbrella, running on the same rolling-release scheme and semi-automatic infra. Cheers, Ettore Il giorno dom 11 ott 2015 alle ore 13:17 Geaaru <[email protected]> ha scritto: > Hi, > > I'm sorry from me for so long delay on reply. > > I'm trying to explain what I want to do... > > Openstack platform is very complicated and probably for maintain different > releases it is wrong follow gentoo ebuild where all packages are in slot 0. > > On my layman I create new ebuild for simplify and clarify management of a > lot of python libraries for permit (as phase1) support to Juno release with > lock of different slots. > For example for package sys-auth/keystone I mask gentoo SLOT 0 ebuilds > (through a file inside /etc/portage/package.mask.d/) and leave only my > ebuilds. > > [?] sys-auth/keystone > Available versions: > (2014.2-juno) ~2014.2.3-r1[1] > (0) [m]2015.1.1 [m]**2015.1.9999 > (2015.1-kilo) ~2015.1.1[1] > > and it is possible install SLOT 2014.2-juno release only if not present > same package of SLOT 0 and 2015.1-kilo. I know, SLOT feature is born to > handle multiple installation of same package, but I try to use it to > structure compilation of software. > > I do this because on Juno and Kilo releases there are a lot of > dependencies that use python library old, for > example dev-python/oslo-messaging for cinder has this dependencies > restrictions: > > oslo.messaging>=1.4.0,!=1.5.0,<1.6.0 > > (at least as describe on requirements.txt file). > > In gentoo ebuild maintain only a single SLOT 0 for handle all version > means produce a lot of conflits and problems on compilation through emerge > and consequently also on sabyon packages where are present. > > How can I manage this ? > > A first solution is that I can use SLOT feature for handle different major > release of library used on opentack for permit creation on different > version of packages on same sabayon repository. This solution is possible > but introduces other problems for other packages that require a newest > version of same libraries. > So, a second solution is handle different SLOT and save packages on > different repositories like I think we do for sabayon desktop release and > sabayon server release. > > Obviously, for to do this I prefer maintain both sabayon repositories for > all other packages and mask automatically packages used on openstack > repositories and also available on sabayon repositories. > > For what I see there are meta file inside every repository created with > eit related with packages.db.meta file ... The idea is push inside this > meta file about mask a rule like this: > > dev-python/stevedore@sabayon-weekly > dev-python/[email protected] > > Is it possible to do this ? I see eit command but I haven't found a way to > handle packages.db.meta database. > Can I use packages.db.meta database for mask packages inside sabayon > repositories and force packages inside openstack repository? > > I think that with initiative of support Sabayon server edition, add > support to an Openstack ready platform could be very powerful. WDYF ? > > Thank you very much for support. > > G. > > P.S. And sorry in advance for delay on replies but I have very few time. > > > On Tue, 2015-09-29 at 15:18 +0000, Ettore Di Giacinto wrote: > > Hi, > Sorry for the late answer, > > I'm not getting clearly what are you trying to do but i'll try to answer > as better as i can: > > 1) Not that i'm aware of > > 2) Not that directly that i'm aware of, but if you go on the > /etc/entropy/packages there are some files that can help you > (packages.db.post_update.sh.example should fit your case, you need to check > if the packages is already installed, and then trigger an install) > > Anyway, i would try a different approach: if you need something useflag > enabled by official repository, we can try to do our best to fits your > needs. But if i was in you i would try to keep all the packages in one > repository, or trying to solve the deps problems in a more cleaner way > (that is easier also to mantain, for you) > > Cheers > > > Il giorno dom 27 set 2015 alle ore 11:52 Geaaru <[email protected]> ha > scritto: > > Hi guys, > > I have two questions about how can I manage installation of packages fr > om a particular repository. > > Let me explain my use case. In my case I'm trying to create three > different repositories for permit installation of all available three > of openstack framework: juno, kilo and liberty. > > These major release has different dependencies of same packages so for > manage these dependencies I create different SLOT and fix dependencies > directly to ebuilds of my overlay. > > I think that I will try to manage these three openstack major release > through three sabayon repository with eit command. > > So, my questions are: > > 1) With sabayon repository is possible automatically mask packages of > sabayon-weekly/sabayonlinux.org repository without create a file under > /etc/entropy/packages/package.mask.d/ directory ? Is there a logic like > for package.mask under profiles directory that is override automacally > when it is installed a portage overlay ? > > 2) is it possibile handle automatically installation of a particular > package when I enable a particular repository ? The idea is that when I > enable openstack-juno repository automatically is installed a package > that add file under /etc/entropy/packages/package.mask.d directory that > mask libraries used by openstack framework from sabayon-weekly > repository. > > Thanks in advance for any feedback. > > Geaaru > > > > >
