Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Dawid Weglinski
2018-03-08 3:38 GMT+01:00 Benda Xu :

> Dear Rich,
>
> Rich Freeman  writes:
>
> > Everybody I know has these sorts of complaints about language-based
> > PMs, whether they prefer Ubuntu, or Debian, or CentOS, or whatever.
> > Nobody wants random programs downloading random stuff and dropping
> > orphan files all over their filesystem with no way to identify these
> > or clean them up.  They're usually written by the same sorts of people
> > who tell you to pipe curl into sudo bash...
>
> One observation.  There are a lot of people on this planet who will
> format their disk and reinstall their whatever operating systems upon
> getting fscked by random programs downloading random stuff and dropping
> orphan files all over their filesystem.  So far the volume of this group
> of people is growing fast.


I'm glad there are people who can take care of their stuff on desktop, but
imagine,
there are plenty of those, who run Gentoo on production and do not wish
some POS
to broke their system.




> That give an illusion of tolerance from the users, enouraging this evil
> to go deeper.
>
> Luckily in Gentoo, we are with competent friends who are taking care of
> their own systems.
>
> Cheers,
> Benda
>
>
>


-- 
Pozdrawiam
Dawid Węgliński


Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Benda Xu
Hi Folks,

Michael Orlitzky  writes:

> These other package managers don't solve any hard problems -- they're
> basically a fancy interface around wget and "git clone." Portage on the
> other hand has ~20 years of good ideas and hard work on the hard
> problems in package management. For example...

I just want to point out one very nice article by Michael thoroughly
discussing there issues:

  
http://michael.orlitzky.com/articles/motherfuckers_need_package_management.xhtml


This title itself is amusing enough

  Motherfuckers need package management


Benda








Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Benda Xu
Dear Rich,

Rich Freeman  writes:

> Everybody I know has these sorts of complaints about language-based
> PMs, whether they prefer Ubuntu, or Debian, or CentOS, or whatever.
> Nobody wants random programs downloading random stuff and dropping
> orphan files all over their filesystem with no way to identify these
> or clean them up.  They're usually written by the same sorts of people
> who tell you to pipe curl into sudo bash...

One observation.  There are a lot of people on this planet who will
format their disk and reinstall their whatever operating systems upon
getting fscked by random programs downloading random stuff and dropping
orphan files all over their filesystem.  So far the volume of this group
of people is growing fast.

That give an illusion of tolerance from the users, enouraging this evil
to go deeper.

Luckily in Gentoo, we are with competent friends who are taking care of
their own systems.

Cheers,
Benda




Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Rich Freeman
On Wed, Mar 7, 2018 at 3:55 PM, R0b0t1  wrote:
> On Wed, Mar 7, 2018 at 1:15 PM, Alec Warner  wrote:
>>
>> Because containers are awesome and are way easier to use.
>>
>
> I think you missed my point: Why are they easier to use?
>

I suspect that he was equating "containers" with "Docker," which both
runs containers and also is an image management solution (one that I
don't particularly like, but probably because I don't have heavy needs
so I find myself fighting it more than anything else - it doesn't hurt
that for the life of me I can't get it to connect containers to my
bridge, and it seems like it is completely opposed to just using DHCP
to obtain IPs).

But, if you're using Docker, sure, you can run whatever the command is
to download an image of a container with some software pre-installed
and run it.

If you're using something other than Docker to manage your containers
then you still have to get the software you want to use installed in
your container image.

-- 
Rich



Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread R0b0t1
On Wed, Mar 7, 2018 at 1:15 PM, Alec Warner  wrote:
>
>
> On Wed, Mar 7, 2018 at 1:22 PM, R0b0t1  wrote:
>>
>> On Wed, Mar 7, 2018 at 11:52 AM, Alec Warner  wrote:
>> > On Wed, Mar 7, 2018 at 11:51 AM, Michael Orlitzky 
>> > wrote:
>> >>
>> >> On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
>> >> > Why should portage download some outdated second copy of the
>> >> > sources for 'bar', rebuild it, and scatter it around the file system
>> >> > where it cannot be used by other programs installed by cabal?
>> >>
>> >
>> > I'm really not happy with the tone of this email, so I'm going to
>> > comment on
>> > it a bit.
>> >
>>
>> I can't help but agree with Mr. Orlitzky's sentiment. All language
>> package managers suffer from the same sophomoric problems:
>>
>>
>> 1) I usually don't know where things are downloaded from.
>> 2) I can't integrate these changes with my distrbution (Gentoo,
>> Ubuntu, Debian, Fedora, CentOS) safely without serious work.
>> 3) I can't figure out easily what dependencies a package has. Usually
>> I see if there are compile or runtime errors. Sometimes the
>> dependencies are listed somewhere. If the dependency is not what is
>> currently in e.g. Ubuntu's repository, I may have to maintain separate
>> versions to be compatible.
>> 4) Sometimes they aren't set up to be built at all. Let the magic
>> package manager do everything for you. This works, except when your
>> shared objects are not in the right places. (But it makes me feel
>> dirty.)
>>
>> >>
>> >> These other package managers don't solve any hard problems -- they're
>> >> basically a fancy interface around wget and "git clone." Portage on the
>> >> other hand has ~20 years of good ideas and hard work on the hard
>> >> problems in package management. For example...
>> >
>> >
>> > Portage is also full of not-good ideas; many of these we papered over
>> > with
>> > PMS and EAPI to make
>> > the actual API people use less horrific. Lets not preach from our ivory
>> > tower here.
>> >
>>
>> The magnitude of "not good" is, I would suggest, very different.
>>
>> Cabal is a pretty hilarious example. Have you ever tried to build it
>> without using the release binaries? I suppose this is a second problem
>> though, where people want to be "self-reliant" and instead just end up
>> making things impossible to verify or make reproducible.
>>
>> For the longest time Cabal did not authenticate or verify the code it
>> would run (as root). Very recently this was fixed, but I still feel
>> bad any time I let it run, even if it's on a separate development
>> system.
>
>
> Gentoo just got signature checking enabled by default...in ~arch? I'm not
> sure if that version of portage is stable yet.
> Like I said, be careful how one preaches from the ivory tower.
>

webrsync-gpg has been an option for a long time.

Package maintenance for Gentoo is not the ivory tower. If anything,
the ivory tower is language development, in that tower the language
developers are isolated from the wider reaching consequences of their
actions.

>>
>>
>> >>
>> >> > It seems reasonable to me to 'hook' portage into these other package
>> >> > managers, so that running 'emerge bar' would actually run 'cabal
>> >> > install
>> >> > bar'
>> >>
>> >> Can "cabal install" build or even identify the C libraries that your
>> >> Haskell package needs? No, because nobody ever thought of that, and it
>> >> seems kind of hard now that the cabal build system has no ability to
>> >> build non-Haskell packages, so no one is ever going to work on it.
>> >>
>> >> Can "cabal install" rebuild your Haskell packages when the ABI of some
>> >> library changes? No, because "cabal install" doesn't have any idea
>> >> what's installed on your system.
>> >>
>> >> Can "cabal install" uninstall a package? Nope, it has no idea what was
>> >> done during the installation, and thus no idea what to undo.
>> >>
>> >> Can "cabal install" verify the integrity of your downloaded source
>> >> code?
>> >> No, because by design it fetches and runs code from complete strangers.
>> >>
>> >> Can "cabal install" use a local tarball to function without network
>> >> access? Etc. We're dead in the water.
>> >>
>> >> Every other language-specific package manager has the same problems,
>> >> because they're all written by people who didn't know anything about
>> >> package management and then got bored when they realized that there's
>> >> more to it than parsing a json file of dependencies.
>> >>
>> >
>> > They are written by people who are not you, who have different problems
>> > than
>> > you and often don't care about the above use cases.
>> > It turns out this stuff exists because:
>> >
>> > 1) Upstream wants to push 1 single thing and have it work in all
>> > distros.
>> > 2) pip / virtualenv / cargo / whatever work reasonable well.
>> > 3) Rolling-based distros couldn't keep up with packaging.
>> > 4) Snapshot-based distros 

Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Alec Warner
On Wed, Mar 7, 2018 at 3:12 PM, Michael Orlitzky  wrote:

> On 03/07/2018 12:52 PM, Alec Warner wrote:
> >
> > I'm really not happy with the tone of this email, so I'm going to
> > comment on it a bit.
> >
>
> Ok, it would have benefited from a do-I-sound-like-a-dick proofread. I
> don't want to sound discouraging because this is an area with lots of
> room for improvement. A better conclusion:
>
> Ultimately, people want to integrate the various PMs with portage
> because portage is pretty good at keeping your system reliable,
> up-to-date, and secure. The language-specific PMs on the other hand only
> care about ease of use and how fast they can get bleeding-edge releases
> to you. Having both would be ideal, but if we simply shell out to the
> language-specific PM, then that would sidestep the good parts of portage
> making the integration pointless. The time and attention involved in
> ebuild packaging turn out to be critical parts of the product.
>
>
I really appreciate this reply. I also think that portage provides a lot of
value (particularly for complex projects that are perhaps not
so well suited for use with the less featureful tooling.)

-A


Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Michael Orlitzky
On 03/07/2018 12:52 PM, Alec Warner wrote:
> 
> I'm really not happy with the tone of this email, so I'm going to
> comment on it a bit.
>  

Ok, it would have benefited from a do-I-sound-like-a-dick proofread. I
don't want to sound discouraging because this is an area with lots of
room for improvement. A better conclusion:

Ultimately, people want to integrate the various PMs with portage
because portage is pretty good at keeping your system reliable,
up-to-date, and secure. The language-specific PMs on the other hand only
care about ease of use and how fast they can get bleeding-edge releases
to you. Having both would be ideal, but if we simply shell out to the
language-specific PM, then that would sidestep the good parts of portage
making the integration pointless. The time and attention involved in
ebuild packaging turn out to be critical parts of the product.



Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Alec Warner
On Wed, Mar 7, 2018 at 1:22 PM, R0b0t1  wrote:

> On Wed, Mar 7, 2018 at 11:52 AM, Alec Warner  wrote:
> > On Wed, Mar 7, 2018 at 11:51 AM, Michael Orlitzky 
> wrote:
> >>
> >> On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
> >> > Why should portage download some outdated second copy of the
> >> > sources for 'bar', rebuild it, and scatter it around the file system
> >> > where it cannot be used by other programs installed by cabal?
> >>
> >
> > I'm really not happy with the tone of this email, so I'm going to
> comment on
> > it a bit.
> >
>
> I can't help but agree with Mr. Orlitzky's sentiment. All language
> package managers suffer from the same sophomoric problems:
>

> 1) I usually don't know where things are downloaded from.
> 2) I can't integrate these changes with my distrbution (Gentoo,
> Ubuntu, Debian, Fedora, CentOS) safely without serious work.
> 3) I can't figure out easily what dependencies a package has. Usually
> I see if there are compile or runtime errors. Sometimes the
> dependencies are listed somewhere. If the dependency is not what is
> currently in e.g. Ubuntu's repository, I may have to maintain separate
> versions to be compatible.
> 4) Sometimes they aren't set up to be built at all. Let the magic
> package manager do everything for you. This works, except when your
> shared objects are not in the right places. (But it makes me feel
> dirty.)
>
> >>
> >> These other package managers don't solve any hard problems -- they're
> >> basically a fancy interface around wget and "git clone." Portage on the
> >> other hand has ~20 years of good ideas and hard work on the hard
> >> problems in package management. For example...
> >
> >
> > Portage is also full of not-good ideas; many of these we papered over
> with
> > PMS and EAPI to make
> > the actual API people use less horrific. Lets not preach from our ivory
> > tower here.
> >
>
> The magnitude of "not good" is, I would suggest, very different.
>
> Cabal is a pretty hilarious example. Have you ever tried to build it
> without using the release binaries? I suppose this is a second problem
> though, where people want to be "self-reliant" and instead just end up
> making things impossible to verify or make reproducible.
>
> For the longest time Cabal did not authenticate or verify the code it
> would run (as root). Very recently this was fixed, but I still feel
> bad any time I let it run, even if it's on a separate development
> system.
>

Gentoo just got signature checking enabled by default...in ~arch? I'm not
sure if that version of portage is stable yet.
Like I said, be careful how one preaches from the ivory tower.


>
> >>
> >> > It seems reasonable to me to 'hook' portage into these other package
> >> > managers, so that running 'emerge bar' would actually run 'cabal
> install
> >> > bar'
> >>
> >> Can "cabal install" build or even identify the C libraries that your
> >> Haskell package needs? No, because nobody ever thought of that, and it
> >> seems kind of hard now that the cabal build system has no ability to
> >> build non-Haskell packages, so no one is ever going to work on it.
> >>
> >> Can "cabal install" rebuild your Haskell packages when the ABI of some
> >> library changes? No, because "cabal install" doesn't have any idea
> >> what's installed on your system.
> >>
> >> Can "cabal install" uninstall a package? Nope, it has no idea what was
> >> done during the installation, and thus no idea what to undo.
> >>
> >> Can "cabal install" verify the integrity of your downloaded source code?
> >> No, because by design it fetches and runs code from complete strangers.
> >>
> >> Can "cabal install" use a local tarball to function without network
> >> access? Etc. We're dead in the water.
> >>
> >> Every other language-specific package manager has the same problems,
> >> because they're all written by people who didn't know anything about
> >> package management and then got bored when they realized that there's
> >> more to it than parsing a json file of dependencies.
> >>
> >
> > They are written by people who are not you, who have different problems
> than
> > you and often don't care about the above use cases.
> > It turns out this stuff exists because:
> >
> > 1) Upstream wants to push 1 single thing and have it work in all distros.
> > 2) pip / virtualenv / cargo / whatever work reasonable well.
> > 3) Rolling-based distros couldn't keep up with packaging.
> > 4) Snapshot-based distros (debian stable / ubuntu) were not designed with
> > this in mind as much; because packages were developed with a high
> velocity.
> >
>
>
This == upstream has a git tag (release X) and they sync the tag into pip
and they tell people to pip install X and their job is done.
Software, distributed.


> 1) What do you mean by this? Distributions are usually not binary
> compatible. This "works" by having each distribution customize and
> build a project by hand.
>

Right, and because 

Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Rich Freeman
On Wed, Mar 7, 2018 at 12:52 PM, Alec Warner  wrote:
>
> https://wiki.gentoo.org/wiki/Project:Perl/g-cpan is a project is in a
> similar space and basically reads perl CPAN metadata to generate stub
> ebuilds.
> Portage tracks these stub ebuilds (and so for example, it tracks what these
> cpan packages install and can remove them afterwards.)
>

This is the right general approach.  If somebody were willing to do
the work I'm sure it would be useful if portage had a more generic
interface for stuff like this, such as a way to do plugins/etc.  The
idea would be to run some outside package manager in some kind of
sandbox, then create a binary package from what gets installed.

Everybody I know has these sorts of complaints about language-based
PMs, whether they prefer Ubuntu, or Debian, or CentOS, or whatever.
Nobody wants random programs downloading random stuff and dropping
orphan files all over their filesystem with no way to identify these
or clean them up.  They're usually written by the same sorts of people
who tell you to pipe curl into sudo bash...

-- 
Rich



Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread R0b0t1
On Wed, Mar 7, 2018 at 11:52 AM, Alec Warner  wrote:
> On Wed, Mar 7, 2018 at 11:51 AM, Michael Orlitzky  wrote:
>>
>> On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
>> > Why should portage download some outdated second copy of the
>> > sources for 'bar', rebuild it, and scatter it around the file system
>> > where it cannot be used by other programs installed by cabal?
>>
>
> I'm really not happy with the tone of this email, so I'm going to comment on
> it a bit.
>

I can't help but agree with Mr. Orlitzky's sentiment. All language
package managers suffer from the same sophomoric problems:

1) I usually don't know where things are downloaded from.
2) I can't integrate these changes with my distrbution (Gentoo,
Ubuntu, Debian, Fedora, CentOS) safely without serious work.
3) I can't figure out easily what dependencies a package has. Usually
I see if there are compile or runtime errors. Sometimes the
dependencies are listed somewhere. If the dependency is not what is
currently in e.g. Ubuntu's repository, I may have to maintain separate
versions to be compatible.
4) Sometimes they aren't set up to be built at all. Let the magic
package manager do everything for you. This works, except when your
shared objects are not in the right places. (But it makes me feel
dirty.)

>>
>> These other package managers don't solve any hard problems -- they're
>> basically a fancy interface around wget and "git clone." Portage on the
>> other hand has ~20 years of good ideas and hard work on the hard
>> problems in package management. For example...
>
>
> Portage is also full of not-good ideas; many of these we papered over with
> PMS and EAPI to make
> the actual API people use less horrific. Lets not preach from our ivory
> tower here.
>

The magnitude of "not good" is, I would suggest, very different.

Cabal is a pretty hilarious example. Have you ever tried to build it
without using the release binaries? I suppose this is a second problem
though, where people want to be "self-reliant" and instead just end up
making things impossible to verify or make reproducible.

For the longest time Cabal did not authenticate or verify the code it
would run (as root). Very recently this was fixed, but I still feel
bad any time I let it run, even if it's on a separate development
system.

>>
>> > It seems reasonable to me to 'hook' portage into these other package
>> > managers, so that running 'emerge bar' would actually run 'cabal install
>> > bar'
>>
>> Can "cabal install" build or even identify the C libraries that your
>> Haskell package needs? No, because nobody ever thought of that, and it
>> seems kind of hard now that the cabal build system has no ability to
>> build non-Haskell packages, so no one is ever going to work on it.
>>
>> Can "cabal install" rebuild your Haskell packages when the ABI of some
>> library changes? No, because "cabal install" doesn't have any idea
>> what's installed on your system.
>>
>> Can "cabal install" uninstall a package? Nope, it has no idea what was
>> done during the installation, and thus no idea what to undo.
>>
>> Can "cabal install" verify the integrity of your downloaded source code?
>> No, because by design it fetches and runs code from complete strangers.
>>
>> Can "cabal install" use a local tarball to function without network
>> access? Etc. We're dead in the water.
>>
>> Every other language-specific package manager has the same problems,
>> because they're all written by people who didn't know anything about
>> package management and then got bored when they realized that there's
>> more to it than parsing a json file of dependencies.
>>
>
> They are written by people who are not you, who have different problems than
> you and often don't care about the above use cases.
> It turns out this stuff exists because:
>
> 1) Upstream wants to push 1 single thing and have it work in all distros.
> 2) pip / virtualenv / cargo / whatever work reasonable well.
> 3) Rolling-based distros couldn't keep up with packaging.
> 4) Snapshot-based distros (debian stable / ubuntu) were not designed with
> this in mind as much; because packages were developed with a high velocity.
>

1) What do you mean by this? Distributions are usually not binary
compatible. This "works" by having each distribution customize and
build a project by hand.
2) Virtualenv works well, and cabal now has a local installation
option. Still, these are not perfect.
3) Use a git ebuild, or target stable versions. If a project has so
much churn that I can't keep up with it I will find something more
stable.
4) True, but prefix would be a lot better at fixing that problem. If
not that, something like virtualenv.

In the case of either #3 or #4, the distribution developers prefer you
use their package manager to install packages. You are only safe doing
anything else in an environment like virtualenv, which does not exist
for the vast majority of languages. This is why developers will pass

Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Alec Warner
On Wed, Mar 7, 2018 at 11:51 AM, Michael Orlitzky  wrote:

> On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
> > Why should portage download some outdated second copy of the
> > sources for 'bar', rebuild it, and scatter it around the file system
> > where it cannot be used by other programs installed by cabal?
>
>
I'm really not happy with the tone of this email, so I'm going to comment
on it a bit.


> These other package managers don't solve any hard problems -- they're
> basically a fancy interface around wget and "git clone." Portage on the
> other hand has ~20 years of good ideas and hard work on the hard
> problems in package management. For example...
>

Portage is also full of not-good ideas; many of these we papered over with
PMS and EAPI to make
the actual API people use less horrific. Lets not preach from our ivory
tower here.


>
>
> > It seems reasonable to me to 'hook' portage into these other package
> > managers, so that running 'emerge bar' would actually run 'cabal install
> > bar'
>
> Can "cabal install" build or even identify the C libraries that your
> Haskell package needs? No, because nobody ever thought of that, and it
> seems kind of hard now that the cabal build system has no ability to
> build non-Haskell packages, so no one is ever going to work on it.
>
> Can "cabal install" rebuild your Haskell packages when the ABI of some
> library changes? No, because "cabal install" doesn't have any idea
> what's installed on your system.
>
> Can "cabal install" uninstall a package? Nope, it has no idea what was
> done during the installation, and thus no idea what to undo.
>
> Can "cabal install" verify the integrity of your downloaded source code?
> No, because by design it fetches and runs code from complete strangers.
>
> Can "cabal install" use a local tarball to function without network
> access? Etc. We're dead in the water.
>
> Every other language-specific package manager has the same problems,
> because they're all written by people who didn't know anything about
> package management and then got bored when they realized that there's
> more to it than parsing a json file of dependencies.
>
>
They are written by people who are not you, who have different problems
than you and often don't care about the above use cases.
It turns out this stuff exists because:

1) Upstream wants to push 1 single thing and have it work in all distros.
2) pip / virtualenv / cargo / whatever work reasonable well.
3) Rolling-based distros couldn't keep up with packaging.
4) Snapshot-based distros (debian stable / ubuntu) were not designed with
this in mind as much; because packages were developed with a high velocity.




> If you want to eliminate the duplication of effort, tell these people to
> use Gentoo Prefix instead of writing the N+1st crippled PM. Doing it the
> other way around won't work because we'd be replacing one good thing
> with 75 shitty things.


I agree that in theory they could have published ebuilds for Gentoo prefix
and it would have 'worked everywhere' but I think that boat sailed about 10
years ago.

https://wiki.gentoo.org/wiki/Project:Perl/g-cpan is a project is in a
similar space and basically reads perl CPAN metadata to generate stub
ebuilds.
Portage tracks these stub ebuilds (and so for example, it tracks what these
cpan packages install and can remove them afterwards.)

I think this is the most pragmatic approach I've seen used as its mostly an
adapter (to cpan) that just generates ebuilds.
Its plausible that with some careful eclass magic you might be able to make
the installed packages compatible with pip, cargo, etc.

I think its more of a struggle to make it compatible with things like
virtualenv or pip --user though.

-A


Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Michael Orlitzky
On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
> Why should portage download some outdated second copy of the
> sources for 'bar', rebuild it, and scatter it around the file system
> where it cannot be used by other programs installed by cabal?

These other package managers don't solve any hard problems -- they're
basically a fancy interface around wget and "git clone." Portage on the
other hand has ~20 years of good ideas and hard work on the hard
problems in package management. For example...


> It seems reasonable to me to 'hook' portage into these other package
> managers, so that running 'emerge bar' would actually run 'cabal install
> bar'

Can "cabal install" build or even identify the C libraries that your
Haskell package needs? No, because nobody ever thought of that, and it
seems kind of hard now that the cabal build system has no ability to
build non-Haskell packages, so no one is ever going to work on it.

Can "cabal install" rebuild your Haskell packages when the ABI of some
library changes? No, because "cabal install" doesn't have any idea
what's installed on your system.

Can "cabal install" uninstall a package? Nope, it has no idea what was
done during the installation, and thus no idea what to undo.

Can "cabal install" verify the integrity of your downloaded source code?
No, because by design it fetches and runs code from complete strangers.

Can "cabal install" use a local tarball to function without network
access? Etc. We're dead in the water.

Every other language-specific package manager has the same problems,
because they're all written by people who didn't know anything about
package management and then got bored when they realized that there's
more to it than parsing a json file of dependencies.

If you want to eliminate the duplication of effort, tell these people to
use Gentoo Prefix instead of writing the N+1st crippled PM. Doing it the
other way around won't work because we'd be replacing one good thing
with 75 shitty things.



[gentoo-dev] Council meeting 2018-03-11

2018-03-07 Thread Matthias Maier
Hi all,

the next Council meeting will be on Sunday 2018-03-11, 18:00 UTC in the
#gentoo-council channel on Freenode.

We have a fairly short agenda this time:

1. Roll call
2. Bugs with council involvement:

   - GLEP 68
 [1] https://bugs.gentoo.org/649740
 [2] 
https://archives.gentoo.org/gentoo-dev/message/ae4f89a9697f623df500b7d44d66c215

   - GLEP 74
 [3] https://bugs.gentoo.org/648638
 [4] 
https://archives.gentoo.org/gentoo-dev/message/3deff3aec43f9e702dbc53838df32168
 [5] 
https://gitweb.gentoo.org/data/glep.git/commit/?id=30fef42d2186d4742c80526a748c40adc5c8953c

   - Joint venture to deal with copyright issues
 [6] https://bugs.gentoo.org/642072

   - GLEP 14
 [7] https://bugs.gentoo.org/637328

3. Open floor


Best,
Matthias


signature.asc
Description: PGP signature


[gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread anoteros
Having used Gentoo for a few years now, one thing that has been annoying
to me is the tremendous duplication of effort and uphill battle of
creating ebuilds (build recipes) for language-specific packages that
already have their own build systems.

For example, many languages such as Python (pip), Node (npm), Ruby
(gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of
redistributing up-to-date dependencies and ensuring that they build
properly in most environments. Portage, it seems, does not take
advantage of this at all. If I want to install the package 'foo', which
has 'bar' as a dependency (which has been installed through cabal, for
instance). Why should portage download some outdated second copy of the
sources for 'bar', rebuild it, and scatter it around the file system
where it cannot be used by other programs installed by cabal?

It seems reasonable to me to 'hook' portage into these other package
managers, so that running 'emerge bar' would actually run 'cabal install
bar' rather than downloading sources and running 'ghc'. This would make
managing dependencies much easier as versions change, since most (all?)
these alternate package managers have ways of specifying specific
versions of packages or pinning. It would also put an end to the
breakage caused by, for example, running 'pip' as root and breaking all
the python libraries portage has pulled in.

I also notice that there is a GSoC 2018 project for integrating Rust
more closely within Gentoo. It seems to me that allowing ebuilds to be
written like this would help resolve this not only for Rust, but for all
languages with similar build systems (which is most modern languages,
frankly).

The only real issue I see with this is the potential loss of granularity
with USE flags for some of these packages, but having poked around the
sort of language-specific libraries and bindings available, hardly any
have any USE flags available, and those that do only offer debug symbols
or documentation, which many of these other build systems offer as well,
so I doubt this would be an issue for anyone. I could of course be wrong.

Is this a feature/improvement other Gentoo users/developers would be
interested in? If so, I would love to help discuss and potentially help
with its implementation.





[gentoo-dev] Last rites: media-video/qt-recordmydesktop

2018-03-07 Thread Michael Palimaka
# Michael Palimaka  (07 Mar 2018)
# Depends on deprecated Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #649116.
media-video/qt-recordmydesktop



[gentoo-dev] Last rites: media-gfx/qosmic

2018-03-07 Thread Michael Palimaka
# Michael Palimaka  (07 Mar 2018)
# Depends on deprecated Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #644424.
media-gfx/qosmic