Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Brian Dolbec]

On Sat, 11 Nov 2017 12:31:15 -0500
Michael Orlitzky  wrote:


> Essentially,we have two commands to create a directory, "dodir" and
> "do-empty-dir" (which we call "keepdir"). The latter is only necessary
> due to an implementation detail, so it doesn't belong in the user
> interface -- the PM should figure out what to do.
> 
> As far as the actual implementation goes, I'm not sure that
> automatically-generated ".keep" files are better than having the
> package manager maintain its own database. The latter would be more
> complex, but would avoid littering everyone's filesystems with
> ".keep" files.
> 

Well, for:

1) using .keepdir files makes this package manager non-specific, ie:
using a different PM would mean it too sees that it is suppose to be
kept.

2) Most ebuilds don't need/or use .keepdir, so I doubt there are that
   many littering up your filesystem.

3) There already is a database of the files installed by a package.
   But, how does it know which other packages might need to install to
   that directory.  So, what does it do on unmerge of the package.
   Typically, the package manager will refuse to remove a non-empty
   directory after the files it is removing are removed.

4) Creating a single database for these will make the system more
   vulnerable to corruption and data loss.  It would save on disk usage
   and number of inodes used.  But there is a tradeoff between space and
   robustness.  If one .keepdir is lost, it may only affect a few
   packages.  If the database becomes corrupted.  It could potentially
   mean the loss of much more of your installed pkg data. Spanning a
   great deal of the installed pkgs.  In this case simplicity
   of .keepdir is in my opinion, much better than a single db.

-- 
Brian Dolbec 

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michał Górny]

W dniu sob, 11.11.2017 o godzinie 12∶31 -0500, użytkownik Michael
Orlitzky napisał:
> > > and a meta-question,
> > > 
> > >   c) Seriously, empty directories are undefined behavior?
> > 
> > ...and how could they be defined if a directory can be installed by
> > multiple packages and has no explicit ownership?
> 
> I see the problem, but the package manager knows which packages are
> using a given directory. (Portage does, and it is at least easy to
> record that information.)
> 
> Empty directories could be installed normally, and then during an
> unmerge, the package manager could check to see if the empty directory
> is used by any package. If it is, leave it -- if not, remove it. You
> might object that this would slow down the unmerge process, but a clever
> lookup scheme would let you map directory names to packages quickly.
> 
> In fact, such a lookup scheme is already implemented in the filesystem
> itself, leading me full circle to the following idea: if the package
> manager is about to install an empty directory, it could create the
> ".keep" file itself. Then "ls -a $dir" is your lookup function that
> determines whether or not a directory is in use by a package.

What about a directory that is installed empty by multiple different
packages, and non-empty by some other packages?

> Having the package manager handle empty directories solves two problems,
> 
>   1) Use of "keepdir" is inconsistent, because portage is happy to let
>  you create an empty directory without it (even though that
>  operation is illegal).

It is not. It is just not guaranteed to be meaningful.

> 
>   2) The build systems of many packages will create empty directories
>  during "make install", and it's unreasonable to expect developers
>  to "keepdir" them all.

Not all of those directories are really meaningful.

> Essentially,we have two commands to create a directory, "dodir" and
> "do-empty-dir" (which we call "keepdir"). The latter is only necessary
> due to an implementation detail, so it doesn't belong in the user
> interface -- the PM should figure out what to do.
> 
> As far as the actual implementation goes, I'm not sure that
> automatically-generated ".keep" files are better than having the package
> manager maintain its own database. The latter would be more complex, but
> would avoid littering everyone's filesystems with ".keep" files.

Do you care enough to spec this properly, introduce EAPI-conditional
behavior for it and prepare patches for the package managers?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/11/2017 02:58 AM, Michał Górny wrote:
>>
>> Certainly "keepdir" will make the directory non-empty, but with the
>> additional (unwanted) side-effect that the directory won't be removed
>> when the package is uninstalled.
> 
> Wrong. It creates a dotfile inside it, and removes it along with it.

Gotcha, I never tested my assumption that keepdir would keep the dir =P

FWIW, `man 5 ebuild` says keepdir "Tells portage to leave directories
behind..." It's not at all apparent that the "left behind" refers to the
unmerge of some other, unrelated, package.


>>   a) When would you want to use keepdir?
> 
> Because it works.

Makes sense now, thanks.



>> and a meta-question,
>>
>>   c) Seriously, empty directories are undefined behavior?
> 
> ...and how could they be defined if a directory can be installed by
> multiple packages and has no explicit ownership?

I see the problem, but the package manager knows which packages are
using a given directory. (Portage does, and it is at least easy to
record that information.)

Empty directories could be installed normally, and then during an
unmerge, the package manager could check to see if the empty directory
is used by any package. If it is, leave it -- if not, remove it. You
might object that this would slow down the unmerge process, but a clever
lookup scheme would let you map directory names to packages quickly.

In fact, such a lookup scheme is already implemented in the filesystem
itself, leading me full circle to the following idea: if the package
manager is about to install an empty directory, it could create the
".keep" file itself. Then "ls -a $dir" is your lookup function that
determines whether or not a directory is in use by a package.

Having the package manager handle empty directories solves two problems,

  1) Use of "keepdir" is inconsistent, because portage is happy to let
 you create an empty directory without it (even though that
 operation is illegal).

  2) The build systems of many packages will create empty directories
 during "make install", and it's unreasonable to expect developers
 to "keepdir" them all.

Essentially,we have two commands to create a directory, "dodir" and
"do-empty-dir" (which we call "keepdir"). The latter is only necessary
due to an implementation detail, so it doesn't belong in the user
interface -- the PM should figure out what to do.

As far as the actual implementation goes, I'm not sure that
automatically-generated ".keep" files are better than having the package
manager maintain its own database. The latter would be more complex, but
would avoid littering everyone's filesystems with ".keep" files.

[gentoo-dev] keywording ~sys-libs/glibc-2.26

[Andreas K. Huettel]

Hi all, 

in the next days I'll likely re-add keywords to glibc-2.26. So, if you haven't 
fixed your package for build failures yet, now would be the time. 

The tracker is https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26 with 
appropriate subtrackers.

1) Your package needs RPC (and already now fails to build with sys-libs/
glibc[-rpc]). 

See https://wiki.gentoo.org/wiki/Project:Toolchain/RPC_implementation for a 
detailed guide.

2) Your package uses NIS/YP functionality, and builds against / links to 
libnsl. 

Add a dependeny (DEPEND and RDEPEND):
  net-libs/libnsl:0=

You can already safely do this now ( =net-libs/libnsl-0 is a dummy, stable on 
all arches, installs no files, depends on 

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Last rites: app-misc/activylircd media-plugins/vdr-alcd

[Jonas Stein]

# Jonas Stein  (11 Nov 2017)
# The upstream developer and former maintainer asked to treeclean these
# packages, because they can be used only with the Siemens Mediacenter
# Activy 3xx which was produced till 2005. He confirmed, that no user
# is left who needs the package from our tree for this special hardware.
# See also bug #633098. Masked for removal on 2018-01-31
app-misc/activylircd
media-plugins/vdr-alcd


-- 
Best regards,
Jonas Stein











signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Open Build Service

[Michał Górny]

W dniu czw, 09.11.2017 o godzinie 23∶03 +, użytkownik Samuel
Bernardo napisał:
> Hi,
> 
> I send this email to know the devs opinion about Gentoo integration with
> Open Build Service[1].
> 
> When creating specialized images and using an automated process for
> testing before deployment, I think that Open Build Service would be
> useful. It already support all major binary based distros and I think
> that Gentoo could be in there also.
> 
> There is also a subforum with some interesting posts[2], where was
> mentioned some references for Gentoo@OBS.
> 
> I reviewed catalyst scripts and Gentoo workflow when creating the
> package repository, and I think that it could be integrated in OBS. The
> advantage is about creating repositories of binary packages from Gentoo
> that would be used to deploy containers or VMs. This way, updates could
> be applied to the images. OBS will be responsible to compile all images
> that would be associated with their own created binary repository.
> 
> To use the binary repository in Gentoo is suggested to use a nfs share
> for portage/packages directory[3], but it would be a smoother
> integration if emerge gets the packages directly from an url.
> 
> You can ask, but for that why not using a binary disto? Well they're not
> Gentoo... What I mean with this is that all the Gentoo tools, portage
> architecture and the ebuild format that allows for excellent source
> package definition (EAPI), turn it unique. Also the freedom associated
> with Gentoo distribution that, with less effort than the others, allows
> for the creation of new distros. Cross compiling tools are also amazing.
> 
> So why shouldn't I wish to use Gentoo always?
> 
> Well it don't need to be OBS, but since this opensource project have
> some nice ideas, why not starting from there?

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.

> 
> Best,
> 
> Samuel
> 
> [1] http://openbuildservice.org/
> 
> [2] https://forums.gentoo.org/viewtopic-p-7829060.html
> 
> [3] https://wiki.gentoo.org/wiki/Binary_package_guide
> 
> 

-- 
Best regards,
Michał Górny