On 11.04.19 09:44, Mo Zhou wrote:
> Different from that, duprkit's design don't hope to limit> the user with any
> pre-defined "sequence", but enable the users to>
selectively call the functions they need. In other words, the> user can
define how to deal with the prepared source+debian
On 10.04.19 16:56, Helmut Grohne wrote:
Hi,
> I looked into this. Your reasons are sound and you are scratching your> itch.
> This is great.
ACK. It's always good when people make their hands dirty and work on
solving actual problems. Even if the actual output (=code, etc) finally
doesn't get
On Sun, Apr 14, 2019 at 4:02 AM Thomas Goirand wrote:
>
> On 4/8/19 7:16 PM, Shengjing Zhu wrote:
> >> from PPA (source+binary-based).
> >
> > If people just want a PPA which supports Debian, please just take a
> > look at OBS[1].
> >
> > I've seen many upstreams provide packages with OBS, and
On 4/8/19 7:16 PM, Shengjing Zhu wrote:
>> from PPA (source+binary-based).
>
> If people just want a PPA which supports Debian, please just take a
> look at OBS[1].
>
> I've seen many upstreams provide packages with OBS, and most
> distributions are supported.
> Not only deb, but also rpm, from
On Fri, Apr 12, 2019 at 3:27 PM Simon McVittie wrote:
> Flatpak treats /usr as immutable (with the exception of mounting
> "extensions" on pre-prepared empty directories) and mounts it read-only in
> the container. If it didn't, it wouldn't be able to use content-addressed
> storage (the storage
On Fri, 12 Apr 2019 at 10:49:57 +0800, Paul Wise wrote:
> Is there any reason that making /app a
> symlink to /usr (or a directory containing only links to /usr)
> wouldn't work inside Flatpak packages?
Flatpak treats /usr as immutable (with the exception of mounting
"extensions" on pre-prepared
On Thu, Apr 11, 2019 at 7:01 PM Simon McVittie wrote:
> The "app" (directly-user-facing part) in a Flatpak package will be mounted
> on /app and so is expected to be built with --prefix=/app, so you can't
> reuse a compiled binary .deb unless it's for something that happens to be
> relocatable
On Thu, 11 Apr 2019 at 09:54:47 +, Mo Zhou wrote:
> On Thu, Apr 11, 2019 at 09:26:15AM +0100, Simon McVittie wrote:
> > On Thu, 11 Apr 2019 at 07:44:30 +, Mo Zhou wrote:
> > It might be interesting to look at game-data-packager, which is another
> > tool that builds and optionally installs
On Thu, Apr 11, 2019 at 09:54:47AM +, Mo Zhou wrote:
> Any link please? Both apt-file-search and google found nothing.
It's in contrib.
https://tracker.debian.org/pkg/game-data-packager
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi,
On Thu, Apr 11, 2019 at 09:26:15AM +0100, Simon McVittie wrote:
> On Thu, 11 Apr 2019 at 07:44:30 +, Mo Zhou wrote:
> It might be interesting to look at game-data-packager, which is another
> tool that builds and optionally installs .deb files for data that is
> not suitable for the
On Thu, 11 Apr 2019 at 07:44:30 +, Mo Zhou wrote:
> On Wed, Apr 10, 2019 at 04:56:51PM +0200, Helmut Grohne wrote:
> > It seems that a key aspect of this thing is avoiding to (re)distribute
> > sources.
It might be interesting to look at game-data-packager, which is another
tool that builds
Hi Helmut,
Thank you very much for the detailed review! :-)
On Wed, Apr 10, 2019 at 04:56:51PM +0200, Helmut Grohne wrote:
> It seems that a key aspect of this thing is avoiding to (re)distribute
> sources. You give good reasons for why this is needed and I see no need
> to reiterate or discuss
Hi Mo,
On Mon, Apr 08, 2019 at 11:18:14AM +, Mo Zhou wrote:
> The proposed idea is to take some advantages from source-based
> software distribution tools. Examples are available here:
> https://github.com/dupr/duprkit
> https://github.com/dupr/DefaultCollection
I looked into this. Your
> from PPA (source+binary-based).
If people just want a PPA which supports Debian, please just take a
look at OBS[1].
I've seen many upstreams provide packages with OBS, and most
distributions are supported.
Not only deb, but also rpm, from Debian/Ubuntu to OpenSuse/Fedora, and
even Archlinux,
DUR is fine, DPA is fine PPA is not - as it is used before in a totally
different context.
The idea just to require git is really nice, putting all the things into
a single file is not. Not even Arch does it. (patches, install, config
...) - so the default debian dir should be enough.
On Mon, Apr 08, 2019 at 11:18:14AM +, Mo Zhou wrote:
The proposed idea is source-only-based, and is totally different
from PPA (source+binary-based). I'm a PPA user and I don't have
any reason to re-invent yet another PPA.
Sorry I appreciate that *your* idea is different, and effectively
On Mon, Apr 08, 2019 at 03:50:19PM +0300, Tzafrir Cohen wrote:
> Hi,
>
> The README states a directory structure with a top-level collection
> directory, but the repository currently does not include one.
The github.com:dupr/DefaultCollection.git repo is indeed a specification
compliant if you
Hi,
On 08/04/2019 14:18, Mo Zhou wrote:
> Hi,
>
> The proposed idea is source-only-based, and is totally different
> from PPA (source+binary-based). I'm a PPA user and I don't have
> any reason to re-invent yet another PPA.
>
> The proposed idea is to take some advantages from source-based
>
Hi,
The proposed idea is source-only-based, and is totally different
from PPA (source+binary-based). I'm a PPA user and I don't have
any reason to re-invent yet another PPA.
The proposed idea is to take some advantages from source-based
software distribution tools. Examples are available here:
Or DPA (Debian Personal Archive)...
Ondrej
--
Ondřej Surý
> On 8 Apr 2019, at 12:32, Holger Levsen wrote:
>
> On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
>>> At the first glance I interpreted the sentence as
>>> "This will only lead to flamewars"
>>> due to the meaning
On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
> > At the first glance I interpreted the sentence as
> > "This will only lead to flamewars"
> > due to the meaning of bikeshed[1].
> >
> > However, I got a hint from a fellow developer and learned that
> > "Bikeshed" has its own
21 matches
Mail list logo
