pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/lang



On Wed, 03 Jun 2020 14:22:33 -0400
Greg Troxel <gdt%lexort.com@localhost> wrote:

> nia <nia%NetBSD.org@localhost> writes:
> 
> > On Wed, Jun 03, 2020 at 09:40:52AM -0400, Greg Troxel wrote:
> >> Agreed.  We have a longstanding convention of foo and foo-bin.  When I
> >> saw about rust-bin I assumed that it made a rust-bin package.
> >
> > Those packages typically use linux emulation, this one doesn't,
> 
> Some do, and perhaps some don't.  THis is about -bin, not about -linux.
> 
> > so has no meaningful difference in functionality, just in who built it
> > and how, which I don't think matters to users of binary packages.
> >
> > It makes no difference whether you `pkgin install rust` or `rust-bin`,
> > except if 'pkgin install rust' doesn't work...
> 
> Joerg has a good point.  I don't see why you want to prevent both from
> being built, if they work, and available, by reusing the package name.
> Why do you think it's important to have a colliding package name?
> Surely RUST_TYPE leads or should lead to depending on one or the other,
> just like ghostscript-gpl and ghostscript-agpl.  Those are two packages
> that purport to do the same thing, modulo bugs and licenses.   I can
> believe that the differences here are smaller, but I don't think that
> affects the point.

Following the principle of least astonishment I would like it to
be named rust-bin too. The use case is similar to lang/go-bin.
I don't mind if the packages conflict so only one of them can be
installed. The binary emulation argument doesn't hold up because these
packages can, at least in theory, be used on Linux natively where no
emulation takes place.



Home | Main Index | Thread Index | Old Index