On Fri, Dec 18, 2020 at 8:59 am, Raphael Hertzog <hert...@debian.org>
wrote:
On Thu, 17 Dec 2020, Pirate Praveen wrote:
> - ensurance that we use DFSG free code only
> => we can have tool to review licenses of what has been
> downloaded during build and embedded in the binary packages
Then there would not be any value for Debian with such a scenario
as people
can do such analysis on any distro/container.
It would make debian irrelevant.
I don't think so. First the tool is here to help the maintainer do the
assertion, it's unlikely to be 100% automated, it will likely point
out files to inspect manually and so on.
And, as a user, even if the tool exists, I wouldn't want to run it
manually,
I would continue to rely on Debian for the vetting process. I don't
want
to have to do this on my own.
Even with that tool, if we have to change any modules, we will have to
create forks of these modules and publish them and also modify
package.json to use these forks.
gitlab has to do that many times with many rubygems when upstream is
not responsive to pull requests.
> => we are doing bad now because many useful things are not
packaged
> (due to the mismatch between our rules and those
not-longer-so-new
> ecosystems) and when users have to manually install, the
reliability
> goes down...
This I agree, but this could be achived by a mix of vendoring and
individual
packages. We can vendor modules that are specific to a single app
and
package more useful libraries as individual packages.
For this to work at scale, you need to work with the upstream
ecosystem so
that this works out of the box... AFAIK right now adding the required
node
modules in build-depends will not avoid those modules to be
downloaded by
the upstream build system and there's no simple flag that you can
just add
to enable that behaviour. Is that correct ?
You will have to create a patch that removes the packaged node modules
from package.json
See this patch in gitlab,
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/patches/0740-use-packaged-modules.patch#L94
Additionally, you will have to tell webpack/rollup to take modules
installed by apt
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/patches/0740-use-packaged-modules.patch#L35
You may able to also add a plugin to yarn to automate this. If there is
a yarn plugin that checks and prefers the apt installed modules, then
that would work without having to patch the upstream build files. Ruby
does that already with rubygems-integrations package. bundle install
--local will take the apt installed modules without any change in
upstream build tools.
> - possibility to rebuild from source
> => we could have some sort of proxy that would store everything
> downloaded and let us rebuild an identical package without net
access
> even if the remote resources disappear
Why would anyone need to use debian in such a scenario?
I don't know for you but the reasons to use Debian would not be
changed
by the addition of this mechanism. I know that I use only free
software,
that all the tools are easy to install, that some sane default
configuration has been provided by the maintainer, that further
instructions are in README.Debian, etc.
All the current trends are making it easy for developers to ship
code
directly to users. Which encourages more isolation instead of
collaboration
between projects. It also makes it easy for shipping more
proprietary code,
duplication of security tracking or lack of it. Debian and other
distributions have provided an important buffer between developers
and users
as we did not necessarily follow the priorities or choices of
upstream
developers exactly always.
This I agree with. And I believe it still stays true even if we
accept to
vendor large amount of stuff.
We need to be doing what is the buzz of the time. Free Software was
not a
mainstream idea when we started.
I don't understand what you are trying to say here.
The mainstream idea seems to be isolating every project without any
coordination with any other projects, including downstream
distributions. The trend is to ship only one configuration (typically
as a docker container - some projects don't even support building from
source).
With distributions like debian, we care for the whole Free Software
ecosystem. When we do transitions, we make sure every free software
using a library or tool is updated. None of those are mainstream views.
Mainstream view is continue using a dependency version till eternity
and nothing really breaks once it works on the developers machine.
There is even a joke about docker being a way to make sure if it works
on the developers system, then lets ship the developers system to
everyone.
Yes, it is a lot work, but it makes the whole Free Software better by
having updated dependencies for all applications.
Distributions are also way for users to effectively use the Freedom to
modify the software. I don't think having to depend entirely on
developers is a win for users in the long term. Their priorities are
not necessarily best for the users.