gmane.os.netbsd.devel.packages

same name different package (was Re: package repo sanity checking)

Jeremy C. Reed — 2012-05-26T12:41:28



As this point brings us back to

"Re: multiple version of packages with the same PKGBASE"
http://mail-index.netbsd.org/tech-pkg/2008/02/13/msg000338.html
and 
"Re: Apache packages"
http://mail-index.netbsd.org/tech-pkg/2008/11/19/msg002080.html
and other threads.

Again let us make it as easier for end-users.

If a user wants to install "emacs" (just that), is it correct for them 
to get the package known as a "snapshot"? That doesn't sound like a 
vetted release.

I propose that generically we always do:

emacs20 (or emacs2.0) editors/emacs20 or (editors/emacs2.0)

emacs21 (or emacs2.1) editors/emacs21 (or editors/emacs2.1)

emacs22 (or emacs2.2) editors/emacs22 (or editors/emacs2.2)

emacs23 (or emacs2.3) editors/emacs (or editors/emacs2.3)

As for "snapshot" I don't know. Either:

emacs-snapshot or emacs24 or emacs-2.4 (and directory name matching)
and clearly marked in comment line and description as experimental 
version.

(I don't use emacs and so I may not be correct and maybe should use 
apache as

Re: package repo sanity checking

Jeremy C. Reed — 2012-05-26T12:18:38



At first I thought it was confusing or a waste to continue to host and 
mirror old packages.  But now I realize that some may not have updated 
pkg_summary so will retrieve the old versions. This may or may not be 
okay. If missing, this could just encourage them to retrieve a new 
pkg_summary (tool could hint about this). Or we could let them use old 
package.

I was wondering if we should have a schedule to purge, but realize that 
the 3 month lifetime of a branch is good enough. It is probably fine to 
keep the old packages available.

But I don't understand the purpose of keeping them listed in the 
pkg_summary file?  Yes I understand it may make it easier to install old 
version.  But this polutes the output of available packages. pkgin lists 
all the choices; now the end-user pauses to think about it: "Why version 
2.2.6nb9 and 2.2.6nb8 both available?" Well same version but maybe some 
difference and some good reason that the old one is still there. Even 
the default "search" or "avail" output does

Re: package repo sanity checking

Aleksey Cheusov — 2012-05-26T06:24:43

In general I support your idea but have a few comments.


Things like mplayer are absent due to their NO_BIN_ON_FTP flag.
I think the problem here is that we limit the "distribution* of the binary
instead of limiting its *usage* (only by US citizens?).
Personally, I don't care about MPEG-LA. Other open source systems
distribute mplayer/vlc/multimedia software.


Do we really need this file?


It's probably too late to care about PKGPATH which became a part of package *id*
ages ago. I tend to think that it is more feature than bug.

1)
amule (from 1 PKGPATHs)
 amule-2.2.6nb8 net/amule
 amule-2.2.6nb9 net/amule

I don't know about pkgin, but "nih install amule" automatically selects
the highest available version of the package for installation, i.e. 2.2.6nb9.
Also, you can manually select another version, i.e, "nih install
amule-2.2.6nb8".
So, I don't see problems here. pkg_summary is correct.

2)
emacs (from 5 PKGPATHs)
 emacs-20.7nb14 editors/emacs20
 emacs-21.4anb22 editors/emacs21
 emacs-22.3nb17 editors/e

daily pkgsrc CVS update output

NetBSD source update — 2012-05-26T02:21:29

Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
? pkgsrc/net/wget/work
P pkgsrc/databases/sqlite3/Makefile
U pkgsrc/databases/sqlite3/distinfo
P pkgsrc/databases/sqlite3-docs/Makefile
P pkgsrc/databases/sqlite3-docs/PLIST
U pkgsrc/databases/sqlite3-docs/distinfo
P pkgsrc/databases/sqlite3-tcl/Makefile
P pkgsrc/databases/sqlite3-tcl/distinfo
P pkgsrc/devel/rt3/Makefile
P pkgsrc/devel/rt3/Makefile.install
P pkgsrc/devel/rt3/PLIST
P pkgsrc/devel/rt3/distinfo
cvs update: pkgsrc/devel/rt3/patches/patch-lib_RT_Action_CreateTickets.pm is no longer in the repository
cvs update: pkgsrc/devel/rt3/patches/patch-lib_RT_Ticket__Overlay.pm is no longer in the repository
cvs update: pkgsrc/devel/rt3/patches/patch-lib_RT_Transaction__Overlay.pm is no longer in the repository
cvs update: pkgsrc/devel/rt3/patches/patch-share_html_Admin_CustomFields_Modify.html is no longer in the repository
cvs update: pkgsrc/devel/rt3/patches/patch-share_html_Search_Bulk.html is no longer in the repos

Re: How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-26T01:05:48


I grepped the previous build and this lists the ones with the error:
mail/autorespond
mail/dotforward
mail/ezmlm
mail/fastforward
mail/mailfront
mail/mess822
mail/qgreylist
mail/qmail-conf
mail/qmail-filter
mail/qmail-run
mail/qtools
mail/serialmail



after setting pbulk.conf's VARBASE to /var, the build seems to work 
normally and all the mail/* packages that were failing with the 
/var/qmail error built.

John

Re: Packages with non-distributable distfiles

Aleksej Saushev — 2012-05-25T21:23:17


No, this project doesn't have resources. Providing packages
for primary operating systems takes all available resources.


Sorry? Would you prove this statement?

It is really easy. Just setup pbulk cluster for NetBSD/i386 and
NetBSD/amd64 for versions 4.0.1, 5.0.2, 5.1, and 6.0_BETA2,
and build packages for release branch and for trunk periodically and
timely for several combinations of PKG_APACHE_DEFAULT,
PHP_VERSION_DEFAULT, PGSQL_VERSION_DEFAULT, X11_TYPE, MPI_TYPE,
and few others.


"Distfiles that are illegal to obtain" is about IP laws. Otherwise you
can just go into the 'net and find almost anything.


Copying files over and over is more difficult if I can just fetch them
along with pkgsrc. That's what is difficult about it.

That's harsh contrast to your proposal. You could easily live without
paying any attention to those packages that don't even show in bulk
reports, unless you make it so.


And you were pointed that it is completely wrong since they are not
"not-for-dragonfly." They are package

Re: How to deal with bulk build's "/var/qmail" problem?

Aleksey Cheusov — 2012-05-25T21:11:06

And user-destdir?

Re: Packages with non-distributable distfiles

Joerg Sonnenberger — 2012-05-25T21:01:08

Let's leave fictional maintainers out of this. They don't contribute
anything. If there is a piece of software that is generally unavailable,
it is the task of the maintainer to make sure it continues to work.
If you want something non-redistributable to continue to be supported,
become maintainer. That's a pretty simple rule. It is also the only way
to make sure it does continue to work.


There is a lot of crappy ancient software that should just die. I am all
for doing regular spring cleaning, but looking at the Acrobat
discussion, that's just as impossible, because a lot of people are
attached to insecure ancient versions.


Someone will complain. That triggers a timer. It gets fixed or the
package gets removed. No big deal.


If you want to be maintainer of a restricted program, yes, I expect you
to do a certain amount of work. Otherwise the package is just for your
own fun and IMO doesn't belong into the public repository.

Joerg

Re: Packages with non-distributable distfiles

Aleksej Saushev — 2012-05-25T20:44:29


Commercial software isn't updated at the same rate as some packages from GNU.
One could have bought some package up to ten years ago and still
continue using it. Consider one popular operating system from Microsoft.
If the package builds and works, there's no reason to remove it just
because some other people cannot find distfiles.

Abandonware argument is really weird here. We continue supporting
similar opensource abandonware even at the price of mirroring distfiles,
while support for commercial abandonware is basically zero since we
don't need to waste space on file server.

Your original proposal is bad in its current form for similar reasons.
Besides one quarter being too short, if we want to follow proposed rule,
we need service that periodically checks distfiles' availability
and sends public notifications when they become unavailable.
For software that isn't offered publicly, I don't know how you're
going to check it. The cost is annoyingly high, you propose to force
maintainers to do hard work jus

Re: Packages with non-distributable distfiles

John Marino — 2012-05-25T15:15:38

I've solved my problem.
I'm probably not going to be around for the next 4 weeks, so I think 
what I've already said stands on it's own merit.



You may believe what you wish - I've been pretty consistent in saying I 
believe the distfile needs to be available to all users or the package 
needs to be removed.  That's got nothing to do with the "free" software 
movement, but everything to do with equal benefits to all users.



No, that's not true.  I added a comment in addition to each tag 
referencing the message that explains it.  Of all the objections, this 
one is really not valid.




Maybe, but one of the drivers is to make it clear to regular users that 
build from source that the package WILL NOT BUILD and THAT'S EXPECTED. 
We've gotten bug reports on these things, and the user was confused why 
the package was broken.  A nice message like "This package is not for 
DragonFly-i386" is clear to them, no confusion.  The bulk build masking 
is nice, but its not the only reason.

John

Re: Packages with non-distributable distfiles

David Holland — 2012-05-25T14:59:10

 > Infrastructure is needed, rules are needed and must be enforced.
 > This sub-project, pkgsrc, has the resources to do that, but isn't.

Formal rules are needed only when there's a social problem that cannot
be solved by community consensus.

Again: what *problem* are you trying to solve?

 > >>I'm sorry, I'm going to continue to believe that packages that
 > >>require distfiles that are illegal to obtain have no place in a
 > >>package system that serves open source operating systems.
 > >
 > >You may believe it, but your beliefs should not impede others.
 > >We're not GNU, and this world still has IP laws. Some software has to be
 > >bought (licensed) in order to be used, and there's significant number of
 > >users who don't see anything wrong with it.
 > 
 > I said nothing about IP laws.  I said "illegal to obtain".  That
 > has been stated as fact several times.  If you have one of these
 > distfiles, you can't legally give it to me.  That's going nothing
 > to do with GNU or IP.

I'm inclined to agree

Re: How to deal with bulk build's "/var/qmail" problem?

David Holland — 2012-05-25T14:46:34

 > Hmmm -
 > My mk.conf defined VARBASE as "/usr/pkg/var" and so did the
 > pbulk.conf file.  But the packages are installing at /var/qmail.
 > 
 > I was going to change the pbulk.conf value to /var in the hopes
 > that would fix it.

I think there's some djb issue with qmail that prevents the package
from honoring $VARBASE correctly.

Re: Brasero 3.0 - ld: cannot find -lltdl

OBATA Akio — 2012-05-25T13:20:37


I don't know about your whole packages and how to rebuild, but something may
still using /usr/X11R7/lib/libXi.so.6.0 instead of /usr/pkg/lib/libXi.so.6.1.0.

How about output of followings?
% pkg_info -Q REQUIRES gtk3+
% ldd /usr/pkg/bin/brasero
% ldd /usr/pkg/lib/libgdk-3.so.0

Re: Brasero 3.0 - ld: cannot find -lltdl

Maurizio Caloro — 2012-05-25T12:49:37

ok now i have rebuild this list but the error exist anyway. 
please exist other way to solv this ?

powermac$ brasero
/usr/pkg/lib//libgdk-3.so.0: Undefined PLT symbol "XIQueryVersion" (symnum =441)

qt3-libs-3.3.8nb18C++ X GUI toolkit
imake-1.0.3nb1Imake and other utilities from modular X.org
libX11-1.3.5Base X libraries from modular Xorg X11
xmlto-0.0.23nb1Tool to help transform XML documents into other formats
xulrunner-12.0XML User Interface Language runtime environment
vim-gtk2-7.2.446nb4Vim editor (vi clone) with X11 GTK2 GUI
libexif-0.6.20nb1EXIF file library
compositeproto-0.4.1Composite extension headers from modular X.org
expat-2.1.0XML parser library written in C
xz-5.0.3XZ utilities
xchat-2.8.8nb3X11 (X Window System) IRC client, using the GTK2 toolkit
gsed-4.2.1nb2GNU implementation of sed, the POSIX stream editor
py26-xml-0.8.4nb3Collection of libraries to process XML with Python
libksba-1.2.0nb1X.509 library
dirmngr-1.1.0nb2X509 certificate

Re: Packages with non-distributable distfiles

Greg Troxel — 2012-05-25T12:35:47

Aleksej Saushev <asau< at >inbox.ru> writes:


In my view, the real issue isn't a purist position about copyright law.
I don't think anyone is objecting to packages that need a distfile that
you have to buy a license to obtain.  We're talking, I think, about
packages with ancient distfiles (that can't legally be copied) and are
no longer obtainable from the original sources.  That just feels like
clutter.

Re: Packages with non-distributable distfiles

John Marino — 2012-05-25T11:55:56

As quickly as possible because I'm sure others are tired of this 
conversation:

- I don't consider commit privilege when talking about users.
- QC comes with a price.  Infrastructure is needed, rules are needed and 
must be enforced.  This sub-project, pkgsrc, has the resources to do 
that, but isn't.  Any criticism about QC by the user is therefore 
justified.  It's really not taxing to identify a bad package and purge 
it, so stating how hard that is isn't going to fly very far.




I said nothing about IP laws.  I said "illegal to obtain".  That has 
been stated as fact several times.  If you have one of these distfiles, 
you can't legally give it to me.  That's going nothing to do with GNU or IP.



Calling me a stallmanist is wrong - I'm not pro-GNU or pro-GPL.  If you 
have an distfile, great, use it.  Use it with a copy of the package 
makefiles made by you before they were purged.  What's so difficult 
about that?





I think you forgot how the whole things started.  I marked these 
NOT-FOR-DRAGON

Re: Packages with non-distributable distfiles

Joerg Sonnenberger — 2012-05-25T11:53:29

*sigh* Can we please go back to the original proposal? It was very
explicit about NOT covering commercial software as long as there is a
maintainer to ensure that the software can be bought.

I don't commit a package for my own commercial software, because it
would be useless for anyone except maybe my own customers. I consider
vanishingware with restricted licenses pretty much the same. I gave one
good example outside the scope of this proposal to abs< at > already with
Java. I'm perfectly fine with the SAP packages. I am maintainer of the
Python Oracle binding, which is useless without having access to an
Oracle installation. All this cases are fine. I'd call net/skype
border line and lots of other things beyond the border. So far I have
seen no real reason why the rule I gave doesn't cover the relevant
cases.

Joerg

Re: Packages with non-distributable distfiles

Aleksej Saushev — 2012-05-25T11:29:24


Yes, some users are more equal than others one way or another,
not everyone can commit his local changes to the repository.
If you think that quality control comes with no price, you're mistaken,
it takes a good deal of resources.


You may believe it, but your beliefs should not impede others.
We're not GNU, and this world still has IP laws. Some software has to be
bought (licensed) in order to be used, and there's significant number of
users who don't see anything wrong with it.

Some countries are even that strict that deny what is considered "fair use,"
and thus you have to break the law if you want to use some software.


I don't see the reason why users should suffer from purist views of one
or few developers.

What you're striving for is completely different from recent move
towards staged installation as requirement. The latter has clear
technical advantages, but some packages have to be purged out for it.
In constrast, your goal is limited to exclusion of packages
with no other benefit than some k

Re: How to deal with bulk build's "/var/qmail" problem?

Hans Rosenfeld — 2012-05-25T10:36:53

And they should be fixed. All of them. :)

I only noticed it with qmail because it showed up in the "causing most
breakage" list in my builds.


That would be very interesting, although the packages should still be
fixed.


Hans

Re: How to deal with bulk build's "/var/qmail" problem?

John Marino — 2012-05-25T10:11:44


Yeah, I was surprised that it wasn't using $VARBASE, but it's a lot of 
mail packages, not just one.  And other packages install directly to 
/var as well.  Probably wrong, but they do.

I'm building with pbulk.conf VARBASE set to /var, so I'll let you know 
if that makes things better or worse.

John

Re: How to deal with bulk build's "/var/qmail" problem?

Hans Rosenfeld — 2012-05-25T10:03:17

I noticed problems with /var/qmail. I even looked at it for a brief
moment, but then I decided there are more important things to fix (for
SunOS, at least).

I don't know if it is related to the build problems, but the package
shouldn't touch /var at all, it should use ${VARBASE}.


Hans