> The same applies to the GNOME/GTK stack, where Flatpak is the way to go
> for active development. libgtk-3-dev is really only for building Debian
> packages from their point of view, too.
Perhaps, but what matters is not upstream's point of view but Debian
user's point of view.
My perception
On Wed, Feb 17, 2021 at 9:33 PM Johannes Schauer Marin Rodrigues
wrote:
[...]
> And then I run "cargo build". Every time I get a message like:
>
> error: no matching package named `foo` found
>
> I install librust-foo-dev until finally:
>
> Parent pid 535147, child pid 535148
> Child
Quoting Andrej Shadura (2020-11-10 10:27:44)
> On Tue, 10 Nov 2020, at 08:28, Paul Wise wrote:
> > > The current proposal is to reduce the main Packages.xz files size by
> > > splitting[4] out all of the packages that are not intended for users,
> > > writing those into an own file. Those packages
The same applies to the GNOME/GTK stack, where Flatpak is the way to go
for active development. libgtk-3-dev is really only for building Debian
packages from their point of view, too.
But at least GNOME has scheduled releases which enable Debian stable to
maintain it, while npm, pip, gems, cargo
Hello,
(I thought I had sent this mail already, but it looks I haven't)
One of the basic things we want is that users can get the source of
their packages, modify a little, and make a new package for their own
use. So in particular we want to be able to "apt source" and get all
the sources, in
Matthias Klose writes:
> On 11/11/20 8:37 PM, Russ Allbery wrote:
>> Rust and Go both vendor dependencies during their build. Python isn't
>> really analogous; you *can* do something similar with virtualenvs, but
>> (a) Python doesn't really have a build the way that Rust and Go do
>> because
On 11/11/20 8:37 PM, Russ Allbery wrote:
> Simon McVittie writes:
>> My understanding is that Rust and Go code literally doesn't have
>> analogous built-in system-wide search paths for third-party libraries,
>> and when building Debian packages that contain Rust and Go code, we have
>> to invent
On Fri, Nov 13, 2020 at 19:28, Tomas Pospisek
wrote:
This solution seems to be too trivial that nobody would have though
of it, so what is it that I (and I guess many Debianers) are missing?
*t
Additionally these libraries change too fast and most of the time,
there is no long term
On 13.11.20 20:51, Wolfgang Silbermayr wrote:
[...detailed explanation of why the buildlibs proposal for Rust is
necessary...]
Thanks a lot for the explanation Wolfgang!
*t
On 11/13/20 7:28 PM, Tomas Pospisek wrote:
> Hi Antonio (and anybody else that understands the technical problem involved
> here),
>
> I've been reading the whole thread and it seems to me that the reason, why
> Rust/Go build-time "libraries" need to be handled differently from all the
> other
Hi Antonio (and anybody else that understands the technical problem
involved here),
I've been reading the whole thread and it seems to me that the reason,
why Rust/Go build-time "libraries" need to be handled differently from
all the other existing stuff in the world and that "no user ever
On Ma, 10 nov 20, 10:06:24, Paul Wise wrote:
> On Tue, Nov 10, 2020 at 9:28 AM Andrej Shadura wrote:
>
> > Development packages for Rust and Go usually only ship source code.
>
> This reminds me of the proposal for installable source packages that
> one could (Build-)Depend on. Seems like that
Simon McVittie writes:
> I think perhaps the key thing here is that Python does *have* a
> reasonably well-defined system-wide search path for packages outside the
> Python core (/usr/lib/python3/dist-packages). Even if some projects
> prefer to use pip instead of dist-packages, they can't claim
On Wed, 11 Nov 2020 at 14:26:55 +0100, Matthias Klose wrote:
> If you ask some upstreams of Python based software, their recommendation would
> be to use pip, and probably conda (a cross OS distribution focusing on Python)
> to do upstream development. If you ask casual users, you probably will
On Wed, Nov 11, 2020 at 02:26:55PM +0100, Matthias Klose wrote:
> On 11/10/20 10:51 PM, Joerg Jaspert wrote:
> > On 15948 March 1977, Paul Wise wrote:
> >
> >> Does this include the -dev packages for C/etc libraries?
> >
> > No.
> >
> >> I guess it also applies to Haskell and other
On Tue, Nov 10, 2020 at 06:52:14PM -0500, Calum McConnell wrote:
> On Tue, 2020-11-10 at 10:07 +, Simon McVittie wrote:
> > On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> > > I'm confused. We are packaging libraries of language X but then those
> > > packages
> > > will not
On 11/10/20 10:51 PM, Joerg Jaspert wrote:
> On 15948 March 1977, Paul Wise wrote:
>
>> Does this include the -dev packages for C/etc libraries?
>
> No.
>
>> I guess it also applies to Haskell and other statically-linked languages.
>> https://wiki.debian.org/StaticLinking
>
> StaticLinking
On 15949 March 1977, Thomas Goirand wrote:
I'm sorry but I don't understand everything here. If we aren't going
to
have new components like main/contrib/non-free, how will it work? We
main contain a new Packages.{gz,xz} file containing these? I'm
guessing
that it's not just a modification to
On 11/9/20 11:36 PM, Joerg Jaspert wrote:
> [4] We first thought about an entire new archive, but that is much more
> separate, creating a higher workload on maintaining it.
> Additionally, it would create problems following the licenses of
> packages. Then we thought about a new
On 15949 March 1977, Calum McConnell wrote:
The Rust community's expectation seems to be that you would install
cargo,
and use that to download and build the clap package directly from
upstream,
without apt/dpkg being involved at all.
I don't know that that means we should abandon efforts to
On Tue, 2020-11-10 at 10:07 +, Simon McVittie wrote:
> On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> > I'm confused. We are packaging libraries of language X but then those
> > packages
> > will not be used by people who write software for language X on
> > Debian?
> >
On 15948 March 1977, Paul Wise wrote:
Does this include the -dev packages for C/etc libraries?
No.
I guess it also applies to Haskell and other statically-linked
languages.
https://wiki.debian.org/StaticLinking
StaticLinking itself is not enough. This is about languages where the
actual
On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> I'm confused. We are packaging libraries of language X but then those packages
> will not be used by people who write software for language X on Debian?
> Intuitively, should I ever start with Rust, I would've thought that I had to
>
On Tue, Nov 10, 2020 at 9:28 AM Andrej Shadura wrote:
> Development packages for Rust and Go usually only ship source code.
This reminds me of the proposal for installable source packages that
one could (Build-)Depend on. Seems like that proposal would also solve
the issue with Go and Rust, as
Hi,
Quoting Andrej Shadura (2020-11-10 10:27:44)
> On Tue, 10 Nov 2020, at 08:28, Paul Wise wrote:
> > > The current proposal is to reduce the main Packages.xz files size by
> > > splitting[4] out all of the packages that are not intended for users,
> > > writing those into an own file. Those
On Tue, 10 Nov 2020 at 20:29, Paul Wise wrote:
> On Mon, Nov 9, 2020 at 10:37 PM Joerg Jaspert wrote:
>
> > More and more packages are being uploaded into the Debian archive which
> > are only ever used for building packages. These are not only never
> > intended to be installed onto an
On Mon, Nov 9, 2020 at 10:37 PM Joerg Jaspert wrote:
> More and more packages are being uploaded into the Debian archive which
> are only ever used for building packages. These are not only never
> intended to be installed onto an end-user's system, they are even
> actively discouraged from being
Hi everybody,
Short Reason: Too many packages of no use to our users.
Longer reason: Many packages get added to Debian that are of no (direct)
use to our users. Each package adds metadata to the indices that needs
to be downloaded, processed by tools and also clutters up the whole
package list
28 matches
Mail list logo
