[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: texlive organization on netbsd
On Wed, 13 Jun 2018, at 13:14, Mayuresh wrote:
> On Wed, Jun 13, 2018 at 12:36:01PM -0400, Cág wrote:
> > If your concern is the overall package number, then it's not a
> > problem:
> Same thought wasn't applied to python-pip, npm and alike. Presence of
> these make any package in the world available on NetBSD in a few
> moments. Why spare only texlive?
> When there is an easy way out to get whichever package I want, not
> being able to do so quickly does sound a problem to me.
From pkgsrc's perspective, what all these programs do is download
random files from the internet and dump them somewhere in the
filesystem. This is not at all the same thing as installing a package.
You can download random files and do whatever you like with them
without involving pkgsrc, so it's not clear what you need from pkgsrc
to solve your problem.
No one has actually articulated a specific proposal. Here are a couple
of possible proposals. I'm not saying that you intended any of these
things, but until you say what you do intend we're all just guessing:
1- If you don't care what pkgsrc does, but just want to install
software in directories you control using tlmgr/pip/npm/ etc., go
ahead. If it doesn't involve pkgsrc, there's no reason to argue about
it on this list.
2- If you think that tlmgr is a useful program and just want to be able
to install it from pkgsrc (and then use it however you like), then sure,
create wip/tlmgr. As long as the rest of pkgsrc doesn't have to deal
with it and it's just another program that is useful to some people and
which the rest of us can ignore, then I doubt that anyone will object
very hard. There's lots of software in pkgsrc that I don't personally
like, but I'm free not to use it.
3- If you think that pkgsrc should stop trying to package software
written in python, R, TeX, and just assume that everyone will use
pip/tlmgr/etc. then people who use software written in those languages,
and want to manage that software while enjoying the various guarantees
and conveniences that pkgsrc provides, will disagree. As long as
they're willing to do the work of packaging, that's their prerogative.
Certainly anything that is required by other software in pkgsrc has to
be included in pkgsrc, to allow proper dependency management.
4- If you think that pkgsrc should use pip/tlmgr/npm/etc. internally to
install software in LOCALBASE (where it might influence the behaviour
of other packages), you'll get hard rejections of the sort we've
already seen in this thread. Allowing uncontrolled modifications of
the contents of LOCALBASE by things which are not actual packages
If you've been intending 1 while others have been reacting to 4, then
we've all been arguing at cross-purposes.
Main Index |
Thread Index |