OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Dan Weeks (danimaldanimal.org)
Date: Tue Sep 04 2001 - 15:42:35 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    >>>>> "DJB" == "D J Bernstein" <djbcr.yp.to>:
    DJB>
    DJB> Hans Insulander writes:
    >> You do not offer people to choice
    DJB>
    DJB> Some packages in /package allow distributor forks; some don't. This has
    DJB> no relevance to the question.
    DJB>
    DJB> What is the harm of using /package? If the author releases a package in
    DJB> /package, why would you want to move it somewhere else?

    DJB> P.S. Am I the only engineer on this mailing list?

    No, you are not. I've been trying to stay out of this. I am a programmer,
    administrator, and user of many types of Unix and Unix-like systems. I
    don't like /package. I don't care what your reasoning is. I read all of
    your information (and I thank you for providing that information), but you
    haven't changed my mind.

    Any software that I compile and forces me to use a location not of my
    choosing, be that /package or /usr/local or /chimpnet, is wrong. Software
    is to be installed where I want it, not the author.

    As to the point of /package making it easier for developers and users,
    that is pure bullcrap. Almost every user I have to deal with has no clue
    about where stuff is installed and could care less about it. They just
    want it to run. It is invisible to them. It is in some path some tech
    setup and they don't care. A lot of developers (probably not any on this
    list, but many that I work with) don't care either. They set it and forget
    it.

    I also don't like all the config files being in /package. I want them in a
    per machine location, like /etc. If I am mounting a common repository of
    binaries on a large number of machines (and yes, I know how to do it
    automatically with allowances for architecture and OS differences. We do
    it at work for 800+ hosts all the time) I don't need them all to have the
    same config files. Not every machine is serving the same thing. But that
    is just a small issue.

    The main issue here is that the way you do things is not the way that
    OpenBSD has chosen to do things by default. There are plenty of mechanisms
    for users and administrators of OpenBSD to operate in patterns other than
    the default. I understand you don't like it. You have presented your
    arguments and the OpenBSD community has rebuffed you to their satisfaction.
    While it may not satisfy you I think you need to take a step back and
    realize that not every one will agree with you (I certainly don't at this
    time). Please stop trying to force us into your philosophy in this way.
    Changes may or may not happen in the future. Your actions in this matter
    aren't helping anyone here to see your ideas as a clean and clear
    solution.

    The OpenBSD team has made it's decision on the side of safety (rather than
    being sorry about it down the road). I for one like this erring on the
    side of caution. If I or any user wants your packages we can download the
    source and install them on our own. The existence of the ports tree does
    not guarantee your software will be included.

    -dan

    -- 
    dan weeks - codemonkey - http://danimal.org/