[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Packages with non-distributable distfiles
John Marino <netbsd%marino.st@localhost> writes:
> On 5/24/2012 13:33, Aleksej Saushev wrote:
>> Joerg Sonnenberger<joerg%britannica.bec.de@localhost> writes:
>>> On Thu, May 24, 2012 at 02:35:49AM +0400, Aleksej Saushev wrote:
>>>> We have many packages that do have distfile but don't build on some
>>>> This problem is definitly more important than having few packages of
>>>> not as freely available to everyone as software from GNU project.
>>> I think you missed the part where it is simply not legal to distribute
>>> the distfiles. A large part of the cases here are simply useless if you
>>> don't have the file.
>> No, I didn't miss that part. For some software you can obtain distfiles
>> by manually registering and downloading from some (not necessarily original)
>> vendor. Or you could have obtained the distfile seven years ago, and the
>> package still works for you.
> The point is that it doesn't work for everybody.
Yes, so what?
At least each fifth package doesn't build for everybody.
Even less packages work. That's not the reason to remove them.
> The purpose of a packaging system is to build packages. The
> package in question is failing its purpose.
No, it isn't. It does build package. Get the distfile and might build it.
>>> Personally, if I would care about one of the
>>> packages, I would keep a local copy and be done. Let's not talk about
>>> messing up wip without a factual base, e.g. someone mass moving packages
>>> just because they were created at some point and must be preserved.
>> I would do the same. Given that I have around 250 local packages already,
>> it doesn't matter whether I have one more or not. But that isn't the most
>> convenient approach. At least some people do consider it inconvenient.
>> In any case, this particular problem is definitly negligible, given others.
>> Solving it doesn't have any positive impact besides the percentage of built
>> packages in bulk build report.
> More than one person contributes to pkgsrc. It's possible to do
> multiple things at once. We don't have to stop fixing "real
> problems" in order to fix this "negligible" one. We can do both
> simultaneously. The presence of fixable-but-still-broken
> packages has no bearing on the presence of
> functioning-but-practically-impossible-to-build packages.
In this particular case you're fighting to remove packages that might be
still useful for some people in order to appease your unusual tastes.
Removal of packages doesn't fix anything except creating obstacles to
people who are or might be using them. Removal of leaf packages doesn't
have any impact besides numbers in bulk build report. And these numbers
are the only thing that constitutes the "problem" you're trying to "solve."
Seriously, you should really find better place to waste your efforts than
reducing number of broken packages from around 470 to around 470 with no
other effect visible or invisible.
> Not that WIP would suffer if you pushed them
> there, that thing seems to unregulated in every way. More
> garbage would just be a drop in the bucket.
Yes, WIP would suffer.
It carries enough stable packages that would be in pkgsrc already, and
enough software that could be, if only standards were a bit relaxed.
But instead of pushing stable software from WIP to pkgsrc, just like it
was meant originally, the opposite is proposed.
Main Index |
Thread Index |