Re: [gentoo-dev] Open Build Service
On Tue, Nov 14, 2017 at 4:47 AM, Samuel Bernardo < samuelbernardo.m...@gmail.com> wrote: The only feature that would be useful for now is emerge obtaining the > precompiled binary packages to install in containers/VMs from http > rather than nfs[1]. > Samuel, probably I miss something but this should work out of box: https://wiki.gentoo.org/wiki/Binary_package_guide#Web_based_binary_package_host Or do you mean something else? -- Peter.
Re: [gentoo-dev] Open Build Service
Hi Michał, On 11/11/2017 08:09 AM, Michał Górny wrote: > You've put a lot of theory in here but not really a single sentence > on what needs to be done. I'm aware that some people used to be working > on adding some OBS ebuilds to Gentoo but I've no clue about their goal. > > Long story short, if it requires changes to the ebuild format, then you > have to list them and convince us. If it doesn't, then you are free to > play with OBS any way you like. I'll review what will need to be done for the integration. The only feature that would be useful for now is emerge obtaining the precompiled binary packages to install in containers/VMs from http rather than nfs[1]. But I'll do a first code review for the integration and then I'll come back to give the feedback supported by code snippets. [1] https://wiki.gentoo.org/wiki/Binary_package_guide
[gentoo-dev] Last rites: app-admin/python-updater
# Mike Gilbert (13 Nov 2017) # python-updater is obsolete. Utilize PYTHON_TARGETS and # emerge --changed-use to rebuild packages instead. # Removal in 30 days. app-admin/python-updater
Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer
On 11/12/2017 10:21 AM, Ulrich Mueller wrote: > >> * Change the PMS to remove "undefined behavior" and replace it with >> "empty directories must be tracked, and may only be removed once no >> installed package is using them," or something along those lines. >> That leaves the implementation up to the PM. > > How? Look up VDB entries of all installed packages? Note that this > would have to be done for every dir that becomes empty, not just the > ones currently containing a .keep_* file. Not necessarily. I chose the "empty directories must be tracked" wording to avoid that. If the PM were about to remove a directory that wasn't in the database of empty directories, then it could proceed normally. > What problem are you trying to solve? I see typically around 100 > .keep_* files on my systems. These are empty files, so they don't use > any blocks. And 100 inodes system wide looks like negligible usage > of resources to me. If you're asking what problem I was trying to solve by leaving the implementation up to the PM, then I was only trying not to be pushy. If the "automatic keepdir" idea... > * Have portage call its keepdir code on any empty directories in $D > between src_install and pkg_preinst. is workable and if the PM authors are fine with it, then we could spec that.
Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer
On 11/12/2017 08:43 AM, Michał Górny wrote: > > I'm not convinced a QA warning is valid, given that not every empty > directory is meaningful. You're going to either cause people to create > unnecessary 'keepdir's, or to be swamped by false positives. The warning would essentially be saying, "you installed this empty directory, do you need it?" Granted, it would be annoying if the answer was "no" and if my package triggered thirty of them, but then that's a bug (possibly upstream) that should be reported and fixed. On the other hand, if you need the directory, then you should be calling "keepdir" on it -- so in either case I don't think the warning is a false positive. >> * Have portage call its keepdir code on any empty directories in $D >> between src_install and pkg_preinst. > > How does this account for /run and other non-persistent locations? What specific problem do you foresee? The implementation above should be no worse than what we have. Right now, there are a lot of ebuilds that are installing empty directories. Those ebuilds are buggy in one way or another: either relying on undefined behavior, or creating unused directories for no reason. (Many of the first type are not easily fixed, since the upstream build system creates them.) The "automatic keepdir" would still create unused directories, but it would fix the directories that should have been keepdir'd but weren't. This presents the usual problems with /run, but none that we don't already have. Ebuilds that create directories under /run already receive a QA warning not to do that, and those directories are already clobbered on a reboot; that doesn't change. If a package like baselayout wants to create an empty /run, it can do so in pkg_postinst to avoid the ".keep" file. What else am I missing? >> * Change the PMS to remove "undefined behavior" and replace it with >> "empty directories must be tracked, and may only be removed once no >> installed package is using them," or something along those lines. >> That leaves the implementation up to the PM. > > ...and makes interoperability between different package managers > impossible, defeating the purpose of PMS in the first place. Well, that's why I'm asking.. I don't know WTF I'm doing, but I'd still like the proposal to be decent when I give it to the people who do.
