public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Peter Stuge <peter@stuge.se>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
Date: Mon, 26 Jan 2015 17:01:08 +0100	[thread overview]
Message-ID: <20150126160108.27420.qmail@stuge.se> (raw)
In-Reply-To: <CAGfcS_nAQd5fyqVJgzyHn-A1SWdVWE2QDD4C2D+yQ-xTzw0FJA@mail.gmail.com>

Rich Freeman wrote:
> >> I personally find it annoying when people fork projects, decide not to
> >> maintain ABI compatibility with the original project, and then keep
> >> filenames the same/etc such that the packages collide in their
> >> recommended configurations.
> >
> > Some people do it on purpose, with the outspoken goal of doing
> > maximum harm to the original project and lock users into the fork.
> 
> In such cases it probably would be helpful if distros talked to each
> other and agreed to hack the build so that the new files would not
> collide.

Yes, I think that would be very helpful.

Unfortunately, my experience is that package maintainers in (all!)
distros either buy into convenient but wholly untrue propaganda or
simply settle for doing the same as "everyone else".


> That then leaves the upstream package with two choices - keep their
> build the same so that anybody who uses it to develop against their
> library ends up with a build that doesn't work on any actual distro,
> or play nice.

That is sadly a unicorn.


> A NyxOS-like approach where you just prefix EVERYTHING on the system
> might also work.

Yes, this is an interesting idea, and a good way to shield users from
evil.


> there wouldn't be an /etc/init.d, but rather a bazillion
> /pkg/guid/etc/init.d directories or something like that

I guess an abstraction akin to pkg-config could solve the problem.


//Peter


  reply	other threads:[~2015-01-26 16:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-12 12:37 [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl hasufell
2014-07-12 14:28 ` Anthony G. Basile
2014-07-12 14:35   ` hasufell
2014-07-12 15:42 ` William Hubbs
2014-07-12 18:51 ` Dirkjan Ochtman
2014-07-13 17:59   ` hasufell
2014-07-15 14:18     ` Matthew Summers
2014-07-15 14:47       ` hasufell
2014-07-16  7:16       ` [gentoo-dev] " Duncan
2015-01-23  1:51 ` [gentoo-dev] " hasufell
2015-01-23  5:56   ` Michał Górny
2015-01-23  9:05     ` Diego Elio Pettenò
2015-01-23 13:25     ` Anthony G. Basile
2015-01-23 20:18       ` hasufell
2015-01-23 22:37         ` Rich Freeman
2015-01-26 10:43           ` Peter Stuge
2015-01-26 12:08             ` Rich Freeman
2015-01-26 16:01               ` Peter Stuge [this message]
2015-01-26 17:55                 ` Rich Freeman
2015-01-27  0:54               ` hasufell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150126160108.27420.qmail@stuge.se \
    --to=peter@stuge.se \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox