Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

OpenPKG 1.0 Released 222

Posted by michael from the dependencies dept.
Ralf S. Engelschall writes: "I'm proundly announcing today the release of OpenPKG 1.0, the world of cross-platform RPM-based Unix software packaging. A flexible and powerful software packaging facility, OpenPKG eases installation and administration of Unix software across several platforms. It primarily targets the Unix platforms FreeBSD, Linux and Solaris, but is portable across mostly all modern Unix flavors. OpenPKG was created in November 2000 and after over one year of development it is already a mature technology in production use. It is available as Open Source and is further maintained by both my development team at Cable & Wireless Germany and our contributors. For more details visit openpkg.org and ftp.openpkg.org."
This discussion has been archived. No new comments can be posted.

OpenPKG 1.0 Released More

OpenPKG 1.0 Released

Comments Filter:
  • How very useful.
    Whilst Solaris does have package management, it's not as good as RPM.
    Of course, now all you have to do is convince sun to support it :)
    • No we have to convince everybody to use it.
      Nobody like having to find specific versions for their systems. (unless you're source junkies)

  • Congratulations Ralf. (Score:5, Informative)

    by bodin ( 2097 ) on Friday January 11, 2002 @09:47AM (#2823106) Homepage
    Let's just say that Ralf is the commited guy for standard packages.

    http://www.openssl.org/ [openssl.org]
    http://www.modssl.org/ [modssl.org]

    To say a few.
    He's the guy that wrote mod_rewrite back in the old days. Tough guy.

    • Re:Congratulations Ralf. (Score:1, Funny)

      by Anonymous Coward
      Yes, and he should be very pround :-)

    • Re:Congratulations Ralf. (Score:4, Insightful)

      by ichimunki ( 194887 ) on Friday January 11, 2002 @10:17AM (#2823244)
      While I appreciate this work, what I really don't understand is why not work on building a tool that doesn't rely on "packages" so much as it relies on source tarballs that are independent of any packaging system.

      What *I* want (and yes, I am coding this myself) is a system that only knows as much as necessary to get the package from its original source in the rawest form available. Then the system takes the package and builds/installs it using a user account set aside for the purpose of installing non-base software.

      Optimally the package system will help the user write a shareable makefile of sorts and save/share that with other systems that user has and with other users. Then, once the build is done, you zip the build directory back up so that if you should need to work with them again the whole mess is handy.

      At its very best the package system recognizes source sources such as tarballs via FTP and HTTP, but also CVS. And finally some hooks to external information sources (announcement lists, a central log of known changes) so that the user can be alerted to potential upgrades, bug fix releases, and security patches.

      One thing I don't like about RPM/.deb/etc is that they rely way too heavily on a database of what is installed to determine what they will install next. If I don't package my "found" software using the package system, this causes RPM/dpkg to start complaining about stuff it doesn't have that I know it does.
      • Then the system takes the package and builds/installs it using a user account set aside for the purpose of installing non-base software.

        Bah! Why is it that no one suggesting these sorts of things has any operational experience? The chances are that the machine on which you're installing the package doesn't have a C compiler, which tends to make your plans to build from source a little unworkable. The usual answer is people telling me that gcc is available for pretty much every system these days, and that I should just install that. No one seems to have the concept of installing the minimum necessary to get the job done any more, something that's particularly important on public facing (and hence higher security risk) boxen. Sigh.

        • A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

          And can you tell me what the odds of this package system being useful to people on those platforms actually are? I don't know if you've ever worked on a non-x86 platform, but try finding even very popular software packages pre-compiled into *either* RPM or .deb packages with any degree of currency and you'll know what I'm talking about. I cannot count the number of times I would've installed a proprietary package on my Yellow Dog system, or some other complex package that I was not anxious to spend three days compiling just to try it out, but couldn't/wouldn't because no precompiled PPC packages existed or were only from sources I had no reason to trust.
          • > A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

            My OpenBSD firewall. No use locking a system down if a user can build their own tools ...

            I needed to add snort to the firewall and binary packages made that painless.
          • A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

            Every single one of the production systems for which I'm responsible (currently Linux/x86, Linux/SPARC, Solaris/SPARC, Tru64, AIX and OpenBSD). If you'd read my original message, you'd see that the lack of a C compiler was through choice, not lack of availability.

            couldn't/wouldn't because no precompiled PPC packages existed or were only from sources I had no reason to trust.

            That problem wouldn't be solved by a package management system that compiled from source. A source package from an untrusted location is just as bad as a precompiled binary from the same location.

          • A Unix machine without a C compiler? Can you name a few popular systems that have this problem?

            Every production and testing system I work with has no compiler, because we build software on development systems. The compilation and the installation are separate functions.

            There's no reason to install software you don't need, and you don't need a compiler to install a software package.

            One reason not to compile your software everywhere you want to install it is because when you test the software and find that it works on your system, you don't want to invalidate that test by installing a different build of the software on subsequent systems.
          • Well how about AIX for one. Since version 4.0 of AIX, IBM has NOT include a "C" compiler as part of the base operating system. I agree, it can be purchased or GCC can be installed but both of these have negative implications in a corporate environment.

            Purchasing a C compiler costs money and bean counters and the like object to anything that adds to the cost of a box. Using GCC, or for that matter, any software that is not supported by a vendor, is usually strictly forbidden.

            This policy or a similar type varient, has been the standard at almost ALL of my employers (3 fulltime and 14 contract over the past 22 years). On the other hand, development boxes are usually not quite as vigilantly monitored.

            I am not saying this good or bad just passing along some anecdotal evidence that:
            if (sys == Unix) {
            C compiler == TRUE
            }
            is no where near as true now as it once was.
          • A Unix machine without a C compiler? Can you name a few popular systems that have this problem?
            Sure. None of the SGI machines that I have purchased or used came with C compilers, or any compilers of any sort. For the ones that did need compilers, we had to purchase it from SGI.
      • What *I* want (and yes, I am coding this myself) is a system that only knows as much as necessary to get the package from its original source in the rawest form available. Then the system takes the package and builds/installs it using a user account set aside for the purpose of installing non-base software.

        I had this idea myself at one time. Mostly because I think that I have a good name. I figured that windows had wizards to install things, So Linux should have a "Sourcerer". Well maybe you don't find that to be as an amusing pun as I did, but I wish you lots of luck in your project.

        I recall that the guy who started KDE (what's name again?) once mentioned working on something like this.

        I would be interested in help you out on this. I think that my best skill is in designing User Interface, but I can programme as well. If you need some help send me an email...

      • Congratulations, ichimunki (Score:5, Informative)

        by MadAhab ( 40080 ) <slasherNO@SPAMahab.com> on Friday January 11, 2002 @11:56AM (#2823786) Homepage Journal
        Congratulations, you just described the FreeBSD ports system.
      • One thing I don't like about RPM/.deb/etc is that they rely way too heavily on a database of what is installed to determine what they will install next. If I don't package my "found" software using the package system, this causes RPM/dpkg to start complaining about stuff it doesn't have that I know it does.

        You don't necessarily have to package anything to get dpkg to know about it. Simply use the "equivs" program: % apt-cache show equivs
        Package: equivs
        ...
        Description: Circumventing Debian package dependencies
        This is a dummy package which can be used to create Debian
        packages, which only contain dependency information.
        .
        This way, you can make the Debian package management
        system believe that equivalents to packages on which other
        packages do depend on are actually installed.
        ...
         Thus, you can build something from source, install it in /usr/local, and use equivs to generate a fake deb telling the packaging system the foo library is installed, and thus all your dependencies will work.

        On that note, though, I honestly prefer having dpkg and apt-get control all the software installed on my Debian systems. Binary package availibility in the "sid" distribution (or "unstable") is usually only a day or two behind releases of actual source. And for those who fear breakages in sid (which does happen from time to time), there is always the "testing" distribution of Debian, which does not include packages known to be bad by implementing a short waiting period and checking bug tracking systems -- and almost never breaks.

      • do you know how long it would take FreeBSD to install if it had to compile everything? And do you know how hard it is to bootstrap a system into compiling its compiler, etc?
    • Red Hat Packaging Method version 3 (the latest of which is 3.05) is the Linux Standard Base packaging system and has been some time now.

      Debian supports the LSB in this manner via APT - I think that's a nasty solution, and will cause more long term plain tham implementing things like suggested dependencies (and different levels of suggestion), and some other minor things.

      Issues like policy, task packages, and APT are already a reality on many RPM based Linux distributions, so I don't see the technical difference between them really being that great.

      Of course, that won't stop the people who haven't used one or other system from complaining below that one or the other system doesn't do things it clearly has for a very long time.
  • ok, so in a nutshell, no matter what *nix I use, as long as I have openpkg installed, I can install any package?

    In other words, I can burn openpackages to a CD, and install the same packages in BSD, Redhat, and Suse?

    • Re:hmm... (Score:3, Insightful)

      by datajack ( 17285 )
      I very much doubt it.
      Different systems have different requirements in packages. At a minimum
      • Processor & architecture for binaries
      • Filesystem layout
      • Configuration requirements for related software (not everywhere, for instance uses the same inetd.conf format)
      • Dependancies on libraries
      • Naming conventions for packages
      • etc..etc..etc..
      I hate to be a pessimist (OK, that's probably a lie ;) but, as you would still need individual packages for almost every platform, I don't see what the big deal about this is?
      The only thing I can see being good about it is on systems where you don't have a vendor supported pacakging system as good as RPM. But, if it's purely for functionality, why not just port apt?


      • They are pushing the use of source packages,
        that would need to be compiled, hence, they can
        adapt to each platform. They only advocated
        the use of binary packahges when the developement
        tools ( mainly gcc, automake ) are not available.

        It's basically an RPM based FreeBSD ports tree.

        Novel idea.. but am not sure the use of RPM
        is the best choice...

        We shall see..

      • > as good as RPM
        :lol !
        Have you seen apt ?

    • Re:hmm... (Score:5, Insightful)

      by chabotc ( 22496 ) <chabotc&gmail,com> on Friday January 11, 2002 @10:17AM (#2823245) Homepage
      I don't even know how to begin replying to this, but i will give it a try ;-)

      First off, no this will not work. Due to different system calls, C libraries, different architectures (CPU etc), etc etc packages will never be that portable. Java and other (supposed to be..) cross-platform type programs might have a chance, but normal applicaties will not be.

      So, if a 'package' is not portable, what good will this do me then, you might wonder? Well the thing is, that previously, you had to make a different 'build and package tool' implimentation for every platform you want to compile your program on. pkg/ports stuff on BSD, other pkg stuff on solaris, apt on debian, rpm on redhat & other linux's.

      So this is where OpenPKG comes in. You only need to write the 'build and package tool' implimentation once (a so called .spec file). This 'source package' you can then compile on each different architecture and platform.
      (resulting in a binary usable for only that platform).

      This makes cross-platform/architecture distribution a lot easier, and a lot easier to maintain.

      • Re:hmm... (Score:1, Informative)

        by Anonymous Coward
        A someone else has said, the intent is that the source code will be there, therefore allowing use of automake et al in the build process.

        Doable.

        Lets hope that there is sufficient take up to allow proper dependencies to be included and found.
      • They are pushing the use of source packages,
        that would need to be compiled, hence, they can
        adapt to each platform. They only advocated
        the use of binary packahges when the developement
        tools ( mainly gcc, automake ) are not available.

        It's basically an RPM based FreeBSD ports tree.

        Novel idea.. but am not sure the use of RPM
        is the best choice...

        We shall see...

  • Time loss (Score:4, Flamebait)

    by leandrod ( 17766 ) <l@@@dutras...org> on Friday January 11, 2002 @09:50AM (#2823122) Homepage Journal
    RPM was created as duplication of effort, because Debian wasn't willing to rush a half-baked dpkg. Now it becomes a standard. Reeks to me of Microsoft Windows-like storyline.

    Why not just port and use dkpg, apt and associated tools? They were all created to be portable, and are indeed already used in http://fink.sf.net./, http://debian-cygwin.sf.net./ and the like.

    • Re:Time loss (Score:3, Interesting)

      by GauteL ( 29207 )
      This is not very relevant anymore. Almost all distributions and projects have chosen RPM, and there really isn't much point in remaking the decision.

      Besides apt already exists for RPM, and works fine. Since my favourite mirror got APT-enabled I've used it almost exclusively.

      I would like to start seeing *.lsb.rpm soon, guaranteed to work on all lsb-compliant distributions. As long as they are competently created they should be debianizable through alien .
      • I would like to start seeing *.lsb.rpm soon, guaranteed to work on all lsb-compliant distributions. As long as they are competently created they should be debianizable through alien.

        Amen, brother! Score:+1,Insightful (virtual moderator point for you!)

      • Re:Time loss (Score:5, Insightful)

        by Captain Morgan ( 160029 ) <[ude.ipw.mula] [ta] [nagromc]> on Friday January 11, 2002 @10:16AM (#2823241) Homepage
        Right... why not judge the two based on some kind of technical merit, like their features? And it would really be nice if the debian people and the redhat people got together and standardized on the next generation package format that they would both be happy with.

        • Re:Time loss (Score:4, Insightful)

          by GauteL ( 29207 ) on Friday January 11, 2002 @10:26AM (#2823290)
          Why should be judge them on technical merit? Both are perfectly adequate, and even though .deb may be technically better, the main reason for people disliking rpm is the amount of incompetently built rpms available.

          My point is that .deb may be marginally better technically, but it doesn't matter as long as most projects have chosen .rpm, and the cost of remaking that decision is FAR bigger than any advantages.

          I have nothing against debs, I like them. I use Debian a lot. I like it. But there really is no point in advocating that everybody should switch to debs, because it isn't going to happen.

          • Re:Time loss (Score:4, Insightful)

            by mattdm ( 1931 ) on Friday January 11, 2002 @10:30AM (#2823317) Homepage
            I'm not even sure .deb is technically better. There's some things RPM does nicely that dpkg doesn't. (For example, the "one big patch" idea in dpkg means that if you're going to add patches of your own to an upstream package, you need to invent your own structure for keeping your changes distinct, and reinvent it for each package, as far as I can tell. RPM deals with lots of patches nicely, and I think it's one of the reasons that there are so many Red Hat-derived distributions.)
            • Of course there's areas where rpm is superior...just don't tell the Debianites, as you'll have an apt jihad (and apt isn't even deb-specific! dpkg is the package manager!)

              It's relevant to point out that it's possible to put together distributions with crappy dependencies using either rpm or deb.

      • Which mirror is apt-enabled? My main resistance to rpm-apt has been the dearth of packages for RedHat boxes I run.

        Do you run Connectiva or Mandrake?

      • The issue is that with apt-rpm you don't get all the good policy decisions that are usually taken for granted in deb packages. The use of deb (or any common successor to both deb and rpm that is a superset of *both*) coupled with FHS may make it far easier to compare "common" packages floating everywhere, like vendors' ones, to high-quality Debian ones.
    • I agree, from the OpenPKG web site:
      "If the build or install process depends on other packages, OpenPKG will tell you about these dependencies and halt the process until you resolve the dependencies installing related OpenPKG packages. "

      So it doesn't automagicly resolve problems, like apt-get does, which is why, having used both, I prefer apt-get.

      What happened to the effort ot combine rpm and apt ?

      • Re:Time loss (Score:4, Informative)

        by ink ( 4325 ) on Friday January 11, 2002 @10:49AM (#2823417) Homepage
        So it doesn't automagicly resolve problems, like apt-get does, which is why, having used both, I prefer apt-get.

        For the (hopefully) last time: APT HAS NOTHING TO DO WITH THE PACKAGING SYSTEM other than requiring the package system to know about dependencies. APT works just fine with RPM, just as it works fine with debs and I see no reason why it couldn't work with OpenPKG.

    • Why not just port and use dkpg, apt and associated tools? They were all created to be portable, and are indeed already used in fink [sf.net]./, debian-cygwin [sf.net]./ and the like.

      Those are both very interesting projects. Since the superiority of deb format is universally acknowledged, I'm surprised that anybody would consider its dumber sister. Debian distribution is famous as the one that you can upgrade to the next version just by typing "apt-get dist-upgrade". That's very powerful package management. Add to this the huge number of software packages that have already been Debian format and are being actively maintained by Debian package maintainers who seem to be only too keen to share their knowledge of the format...

    • RPM was created as duplication of effort, because Debian wasn't willing to rush a half-baked dpkg. Now it becomes a standard. Reeks to me of Microsoft Windows-like storyline

      RPM wasn't a duplication of effort, more of a parallel development. This happened quite frequently in Linux world of the mid nineties - anyone remember the alternatives to the ext2 filesystem (I can't even remember their names now)? We still see it with the proliferation of journaling filesystems.

      To see it as some anti-Debian conspiracy is to exhibit unfounded paranoia. The Debian project works to its own agenda, and a pace that some find exasperating, so please don't start anti-RedHat FUD on the basis of that.

      As for the merit of porting dpkg, etc. - why would you need to? They already run on most architectures, it just comes down to a choice of distribution. *Personally* I prefer RPM because it handles dependencies and versions in a much more sophisticated manner than debs do. This was borne out of a tedious discussion on my local LUG mailing list, where a Debian contributor bad mouthed RedHat and RPM in particular, and was promptly made to look a fool.

      • No paranoia here, no anti-Debian conspiration -- it's just the usual way things go. There's something better that takes time to get right, someone takes a short cut that has bad consequences but gets to market first, so grabbing both market~ and mindshare.

        The comparision to ext2fs actually works against RPM. In the Linux kernel problem space Linus gets to decide on the standard filesystem, he decides slowly and is conservative so to get technical excellence first. But he simply isn't interested in the distribution problem space.

        Excuse me, RPM handles dependencies and version more sophisticadedly? Sure... but here comes Occam's razor: dpkg's way is much simples and get all the work done with less fuss and more efficiently. RPM has lots of short-sighted unnecessary complications built-in.

        As for your local LUG mailing list, sorry, but local LUGs aren't any standard for technical excellence. Most people there never seen proper system administration, still think MySQL is really a RDBMS, SQL is the relational standard and don't grok functional languages.

        • As for your local LUG mailing list, sorry, but local LUGs aren't any standard for technical excellence.

          The Oxford (United Kingdom) list tends to have reasonably high level of cluefulness thanks to the Universities and number of tech companies hereabouts. The particular people involved in the RPM versus debs discussion, while not being big names in the Linux world, certainly have the bona-fides to know what they're talking about.

          • The Oxford (United Kingdom) list tends to have reasonably high level of cluefulness

            Equally, the GLLUG (Greater London) list has a fair amount of technical knowledge. It's frequented by both kernel and gcc/glibc hackers. Plus all the other stuff you expect from a LUG list -- clueless newbies, flamefests, etc. All the things that make life interesting :-) But overall, it's a pretty sound group.

          • OK, would you care to give the URL to the start of the discussion?

            Anyway I judge mailing lists and newsgroups just as I judge newspapers, by their treatment of issues I know. Usually they are pretty weak on databases and system administration, instead focusing on the latest, fastest, and fadest. Usually they are as chronologically snobish as the rest of our culture, sposing OODBs, OO programming and Red Hat alike against the sounder RDBMS, functional programming and Debian.
    • Hmmm, I'm a little skeptical of this theory. The first Red Hat "Mother's Day" release was in 1995. It didn't include RPM, but did include its ancestor rpp. The first releases of Debian which included the primative version of dpkg were around the same time. I don't think one was significantly before the other -- they were basically in infancy together. dpkg certainly didn't seem more "baked" than rpm at the time.
      • You lack information, please investigate more before passing opinion.

        You are comparing *release* dates, which are totally irrelevant, and so is the initial release state of dpkg and rpp.

        The point is that Red Hat forket dpkg -- rather ignored it altogether -- to create rpm because they suffer from the Not Invented Here syndrome; they didn't want to participate in the political and technical Debian open decision making. And in doing so they created a worse packaging system that has worst policy decisions built in.

        As for the initial state of dpkg and rpm, the point is that dpkg has the future built in, while rpm was and will always be badly crafted.
        • You are comparing *release* dates, which are totally irrelevant, and so is the initial release state of dpkg and rpp.

          No I'm not. Why should Red Hat necessarily go with one unfinished unreleased project over another?

          As for the initial state of dpkg and rpm, the point is that dpkg has the future built in, while rpm was and will always be badly crafted.

          In what way?
          • Yes you are. Red Hat went with an unfinished project because it was their own. Not invented here syndrome, and wanting control.

            In the way that dpkg was made to support sound, forward-looking policies, while rpm just to make things work without giving it much thought. The result is that there is a multiplicity of overlapping tools to help overcome shortcomings of rpm at the same time as it has unnecessary complexity (like versioning), while Debian tools are so well thought-of that even apt was made extensible enough to serve rpm also.
    • You Debian guys are starting to sound like the Mac users of the Linux world.
      • Macs as machines and architecture are still technically far superior to PCs. Silent, energy-efficient and beautiful. Pity it's a closed architecture, but so is the PC becoming.

        Paralleling the Debian/Red Hat situation, PCs' only advantage is soon to became market~ and mindshare.

  • Uses separate RPM repository, no NLS (Score:4, Interesting)

    by bojolais ( 72005 ) on Friday January 11, 2002 @10:06AM (#2823188) Homepage
    I notice that an openpkg-installed package populates their own RPM database, rather than using one that may already be on the system. While this may be due to the fact that they need to store additional information that a default RPM4 database doesn't allow for, it would seem to be a horrible inconvenience to maintain two separate RPM databases... even if one allowed you more cross-platform control.

    Also, I thought it interesting that they favor English as the only language used on Unix machines, and chose not to include NLS support in OpenPKG. And they're not even Americans!
  • It really surprises me that they decided to use RPM package format. It surprised me even more that they decided to create "Yet another package system", while there are many very stable and advanced one, that are just waiting to being ported to "Yet another Unix".

    My personal experience is
    RPM = headache.
    APT = a lot of relieve.

    mjander.

  • Duplication of Effort is *Okay* (Score:5, Insightful)

    by Sargent1 ( 124354 ) on Friday January 11, 2002 @10:17AM (#2823246)
    I've already seen a number of people saying, "Yeah, great, but why didn't you port an existing system [usually Debian's] instead of writing your own solution? We don't need another package management system." This drumbeat of "don't create multiple approaches" opinion continues to get louder, and as it does so irritates me more and more.

    It's *good* that there is more than one way to do it. I'm glad that open source not only provides for the possibility of multiple approaches (the built-in allowances for forking), it has a long history of such.

    Don't like sendmail? Write a different mailer, and perhaps like postfix it will become popular. Think that the available desktop managers were built wrongly? Try coding one using your preferred approach. Having diverse solutions can help improve them all, as features from one program are pulled into others.

    The OpenPKG folks saw a need and decided to base their solution on RPM. You may not think that was the wisest choice, but they get to choose where they apply their effort. There is no One Approach to bind all open-source programmers, no One Application in any given niche to which all should contribute. One of the beauties of OSS is that I can choose where I wish to contribute.
    • It's *good* that there is more than one way to do it. I'm glad that open source not only provides for the possibility of multiple approaches (the built-in allowances for forking), it has a long history of such.

      Choice is good, yes, but there comes a point where you have to realize that choice that creates incompatibilities is not really choice at all.

      RedHat is still going to use RPMs, they won't switch to the new format. Neither will Debian. FreeBSD has ports already, and frankly, it's probably better than this option. OS X has apt, ports, AND its own package format, plus purchasable software.

      Why do we need another option just to have another option? The only way to make it truly universal is to make it source, and that basically gives you FBSD.

      Sure, maybe i'm totally wrong about what this new package system is like, but I don't really care. It's more confusion thrown into the mix, and yet another package format for people to support. It's not worth it. If people are going to duplicate effort, why can' they write software people will use and care about?

      There's no reason for anyone to switch from .deb, and if someone was going to switch from RPM, why not switch TO deb and have a huge base of packages and tons of mirrors to choose from?

      --Dan

  • From the faq: (Score:3, Troll)

    by iomud ( 241310 ) on Friday January 11, 2002 @10:19AM (#2823251) Homepage Journal
    Writing a new packaging tool from scratch was not an option, because it would have required too much time and it was not clear whether we would have been really more successful than others. Instead we picked the solution which provided for all(!) of our essential wishes a good or at least reasonable solution. The RedHat Package Manager (RPM) version 4 is not a perfect solution, but even with its drawbacks and pitfalls it fulfills the fundemental needs of OpenPKG.

    I dont know about you but that doesnt really inspire a lot of confidence in me. Essentially this reads to me like they wanted to quickly extend an inferior package management system. *shrug*

    • > The RedHat Package Manager (RPM) version 4 is not a perfect solution, but even with its drawbacks and pitfalls it fulfills the fundemental needs of OpenPKG.

      I dont know about you but that doesnt really inspire a lot of confidence in me. Essentially this reads to me like they wanted to quickly extend an inferior package management system. *shrug*

      Well, to me it looks like they're acknowledging that no packaging system is perfect. Deb and RPM both do some things better than the other. One is an LSB standard, the other isn't. They made their choice based on that, fair enough.
      • If it's the standard because it's simply widely in use, sort of like that other operating system thats the poorest of reasons. I really dont want to get into why the lsb chose rpm though. All I know is we have a chance to do things the right way this time, if that means re-inventing the wheel ten times I'd be happy to wait if when it's finished it's the best wheel to date. There's nothing like the disatisfaction of knowing you did something half-assed. I can understand if the skill level of those creating the software is a limiting factor to the quality of the end product but I get the distinct impression that these guys know what they're doing.
  • bleh... real men/women compile ;-)

    come on.. who doesn't like configuring/compiling... it's the best way to install a program... you customize towards your preference... if anything at least use ports instead of RPM :-\
    • Ok...

      $ rpm --rebuild package.src.rpm

      done

      • Re:RPM?!?!? (Score:2, Insightful)

        by bojolais ( 72005 )
        Or, even more amazingly...

        $ rpm -ta yourSourceThatAmazinglyHasASpec.tar.gz

        RPM does nothing to keep a system administrator from customizing their own packages, assuming they sit down for five minutes and learn how to modify a specfile. All it does is allow you another level of control over the files (and their dependencies... and integrity) on a system.

  • RPM's (Score:2, Insightful)

    by Will_TA ( 549461 )

    I guess people prefer package managers to tarballs. And I guess RPM is the most popular PM and that is why they have chosen to do it. Mircosofty? Possibly/Probbably - good? that remains to be seen. I think I'll let other people try it before I infect my system with it ;-)

    Incidently, does anybody think it strange that when we create something not Microsofty it slowly becomes Microsofty?

  • The FAQ says that OpenPKG decided to go with RPM over all the others for whatever reasons. What I'm wondering is, why bother limiting yourself in that way? Meaning, isn't it a trivial matter to figure out what package type a file is, and use the appropriate tool to handle it? My point is, I think that rpm, deb, and slackware's format are all mature enough that you can't really argue one over the other without getting into taste. Wouldn't the REALLY smart move be to try to come up with a tool that offers convergence? (not saying that nobody hasn't, but I am saying that I think it's an outdated idea to go with one specific format over any other)

  • It's too bad (Score:4, Informative)

    by DaveBarr ( 35447 ) on Friday January 11, 2002 @10:38AM (#2823366) Journal
    There's two main roads to take when trying to develop a solution for this problem. The first way (the OpenPKG way) is to pick a package system and use it across all your platforms. This ensures that your package system will be incompatible with the majority of your systems. (As a side note, it is too bad that they chose RPM on top of this). However, you at least get to use one tool for all the stuff you add.

    The other road is to develop a meta-package system which "wraps" the existing native package system. This ensures the two package management systems don't stomp on each other, and allows you to interoperate with the native package management system (Sun's pkgadd, HP's depot, SGI's inst, etc). As many of us know it can get extremely ugly when a package management system starts getting out of sync with what is actually taking place on a filesystem.

    To put in a shameless plug (I'm only a customer) for some very cool quasi-commercial effort in this area, we use software packaged by The Written Word [thewrittenword.com]. (yeah, strange name). Their software is of the latter philosophy.

    I say quasi-commerical because while they sell distributions packaged on their tools for profit (and provide support and updates for their software by subscription, allowing me to concentrate on my normal duties, not worrying about recompiling this and that when the latest exploit comes out) they are actively involved in open standards-based efforts to develop a true cross-platform open package management system. And by my understanding are committed to switching their system to an open standard once it is standardized and of a sufficient functionality.

    Either way, as Debian users know, the important part is not that you pick a good package system. The important part is that you pick a system that is well maintained, so when the next fix for exploit comes out you know that within a short period of time you can run {apt-get,pkg-inst,whatever) and get a working fix installed.

    The biggest problem with many of the other package systems out there (Sunfreeware, Red Hat Contrib) is not that the package system is necessarily bad, it's the fact that the people don't maintain the packages. They're either woefully out of date, or compiled with beta snapshots of gcc or libc, have incorrect or missing dependencies, or simply haven't been tested.

  • Too little, too late (Score:1, Insightful)

    by Anonymous Coward
    Nice try guys, but no. Unix is already too segmented and this packaging system will not change things one bit. This is a non-NLS supporting, non-GPL'd implementation of an uninspiring packaging system which may or may not support other versions of Unix besides Solaris, BSD, and Linux. Their FAQ [openpkg.org] even contains the question "OpenPKG breaks with a few things from the good old Unix days. Why?" Thanks, but no thanks.

  • The problem with this... (Score:4, Informative)

    by printman ( 54032 ) on Friday January 11, 2002 @10:45AM (#2823392) Homepage
    The problem with this is that is requires the RPM software on all target systems. This won't be popular with a lot of sysadmins because most want to stick with the vendor packaging systems whenever possible so that only 1 install tool needs to be learned and so that dependencies between packages are handled consistently.

    RPM's source-centric view (where you have to rebuild everything from scratch all the time, making development of the initial distributions extremely time consuming) is also a major problem, because a lot of packages take a long time to compile (we have one that takes several hours on older hardware), and you may be testing fixes, etc. that only affect a single executable in your package.

    Anyways, for people that want something a lot more portable and flexible, see my (also free) EPM software at "http://www.easysw.com/epm/". It does native RPM, DPKG, *BSD pkg, System V pkg, IRIX inst, HP-UX swinstall, Tru64 setld, and AIX installp packages, or so-called "portable" install scripts with tar files, all from the same software description/list files. Utilities are provided to automate the building of the list files from already-installed files/directories (the classic RPM BuildRoot stuff) or by intercepting "install" commands, making it very easy to create and/or maintain them.
  • When I read the title I first thought about
    openpackages "the new standard for open source binaries"

    http://www.openpackages.org

  • I'll never tourch RPM again if I have too (Score:5, Insightful)

    by smnolde ( 209197 ) on Friday January 11, 2002 @10:55AM (#2823447) Homepage
    The first time I typed "make install clean" in the FreeBSD ports tree I told myself I'd never do roothat again or RPMs again.

    Since FreeBSD can run the huge majority of linux applications that I need/want, i have no need to get into RPM-hell again.

    If I need to upgrade a system I use cvsup to apply the necessary patches to my source tree and make the world. If I want to update applications, I cvsup my ports tree and run portupgrade. There's nothing easier and it's very rare anything goes wrong.

    So, why build this OpenPKG thing in the first place? VC money down the tubes. I'll keep my ports and packages, but I'll never run RPMs again.

    • Of course BSD doesn't have this problem: the tree is maintained by a very small number of groups, all of whom are in close communications with each other, so they keep their dependancies well groomed.

      Same thing with Debian: small number of groups creating packages, therefor the dependancies are well maintained.

      Now, RPM is used by a very LARGE number of groups, many of whom are not even aware of each other's existance. Furthur, some of those groups are very sloppy about the dependancy data they add to their packages (my favorite: I want version 1.2.3-pl5-v4-x_i686_mmx_with_asm_x-thursday-4_31_b uild_3 of this package, and I won't accept any other version DAMMIT!).

      The problem is NOT in the package format, it is in the absense of any centralized agency performing QC on the builds.
    • Since FreeBSD can run the huge majority of linux applications that I need/want, i have no need to get into RPM-hell again.

      If I need to upgrade a system I use cvsup to apply the necessary patches to my source tree and make the world. If I want to update applications, I cvsup my ports tree and run portupgrade. There's nothing easier and it's very rare anything goes wrong.

      Very good. So what do you do if you want to install binary-only packages that don't have corresponding source (VMWare comes to mind as one such package, though it might not be ported to FreeBSD)?

      Ah. I see. You just install it and track it manually.

      Well, as a system administrator, that's not good enough for me. The reason I like to use a package management system is that it makes it EASY to manage the huge number of files on my system. If I'm not sure what bit of software a particular file belongs to, I can query the package manager (not every file has a manpage, you know). Can you do that with ports?

      Ports is an awesome way to keep your system up to date, but don't confuse it with a good package manager. They serve different needs.

  • Why RPM? (Score:5, Insightful)

    by Anonymous Coward on Friday January 11, 2002 @10:55AM (#2823449)
    When I started using Linux, there was RPM, but then I found dpkg and apt and have never gone back.

    Last week, I tried FreeBSD for the first time. I was very impressed with the ports tree and pkg_add.

    What would be the compelling reason to use openpkg on systems with package managers better than RPM?
    • I'm all rooting for OpenPackages (not OpenPKG) to get stable. It won't cover Solaris, but it will cover Linux, Darwin and OSX.

      But that said, I see one advantage to OpenPKG. Since the binaries inside the OpenPKGs will be different, they aren't portable. The advantage must be that the numbnut build managers at these companies only have to learn one tool. I don't see any advantages for the enduser.

  • FreeBSD pkg_add (Score:5, Informative)

    by Shooter6947 ( 148693 ) <jbarnes007NO@SPAMc3po.barnesos.net> on Friday January 11, 2002 @11:08AM (#2823509) Homepage
    How is this new system different/better than the FreeBSD pkg_add? When I want to download an install a precompiled binary I just type (as root)

    pkg_add -r gnupg

    for instance and the binary package gets automatically ftped down, unpacked, and the pieces installed to the correct locations. With thousands of FreeBSD ports already set up, why should I or anyone switch to this new system?
    • With thousands of FreeBSD ports already set up, why should I or anyone switch to this new system?

      To add to your point, the only reason anyone would use this is because FBSD ports doesn't come with Linux. If you must run Linux though, run Debian, as it's just as easy as FreeBSD.

      apt-get install gnupg

      If you use Linux, use Debian, if you use BSD, use FBSD. This new package system is useless.

      --Dan

  • Can anyone summarize how this differs from RPM? (Score:2, Interesting)

    by Anonymous Coward
    I read the FAQs and scanned the slides, but I didn't see how this differs from RPM. Am I just missing something?

    With RPM, I have a single source RPM, and can build that to create a binary on (theoretically) any architecture (assuming my spec file, etc, take quirks into account.)

    Oh, I see that OpenPKG offers a way to download a file and install it, without explicitly already having RPM on your system. Nice but I'm sure there are more perks I'm missing, otherwise this just looks like a rebranded RPM to me.

    Enlighten me, please.

  • Cross-platform? (Score:3, Insightful)

    by jlusk4 ( 2831 ) on Friday January 11, 2002 @11:31AM (#2823637)
    How is that when MS says "It's cross-platform: it runs on Win98 AND Win2000" we all snicker, but when somebody says "It's cross-platform: it runs on all flavors of Unix" we don't even blink?

    To me, true cross-platformness includes the ability to run on AS/400s, S/390s and VMS. Like emacs or slickedit or... perl?

    John.
    • Cross-platform

      Linux definition

      "Runs on Linux and Windows"

      Macintosh definition

      "Runs on Macintosh and Windows"

      Windows definition

      "Runs on Windows 2000 and Windows XP"

    • Re:Cross-platform? (Score:2, Insightful)

      by ignavus ( 213578 )
      "Win98 AND Win2000" - single vendor

      "all flavors of Unix" - many competing vendors

      There is a difference.

      And "cross-platform" != "universal"

      Does slickedit run on CP/M? AmigaDOS?

  • Has anyone actually read their documentation? (Score:4, Informative)

    by Florian ( 2471 ) <cantsin@zedat.fu-berlin.de> on Friday January 11, 2002 @11:50AM (#2823754) Homepage
    If you had, then you would know that
    • it uses a modified, incompatible version of rpm which will will coexist with "normal" rpm in case the OS it includes the latter. (Unfortunately, the OpenPKG executable is called "rpm" as well, but resides in a different path)
    • it builds its own repository/package database separate from the core OS packages
    • it uses its own particular filesystem layout
    • it doesn't provide apt-like functionalitySo OpenPKG does not replace existing package systems, but is meant as a secondary package system for OS-independent userspace tools (thus allowing to share installed packages across different Unix-like OSs). It breaks all Unix/Linux filesystem/compatibility standards, creates headaches by installing itself as a secondary package manager/database, and thus is unlikely to be widely adopted. (Seems rather like a possible solution for sysadmins who want consistent application installations acrosses different flavors Linux/FreeBSD/Solaris).
  • Is it just me or is the fact that this thing even supports binary RPM's self-defeating? How is that going to be cross-platform??

    Mind you, using the RPM system is pretty self-defeating too.

    TWW

  • A lot of folks are mentioning ports trees . . . anyone who's taken a look at the GNU/Linux port of the FreeBSD ports tree will note that it takes an incredible amount of hacking to get that tree to work under Linux.

    Gentoo Linux (http://www.gentoo.org [gentoo.org]) is building a ports-like tree called Portage, based on Python rather than a mix of Makefiles and shell scripts. It combines the features of cvsup (actually, it just calls rsync; the command to update the portage tree is "emerge rsync"), make install (emerge blah.ebuild) and portinstall (emerge blah/blah). Soon, emerge will have the equivalent up portsupdate.

    The system can install source, create bzip2'd tar packages, or, as an option. RPMs.

  • cross-platform RPM-based Unix software packaging.

    crossplatform: [dictionary.com]

    software, hardware> A term that describes a language, software application or hardware device that works on more than one system platform (e.g. Unix, Microsoft Windows, Macintosh). E.g. Netscape Navigator, Java.

    Using buzzwords, is great and everything if you're a marketing droid, but lets try to be a little more precise among ourselves.

    I'm not trying to belittle this accomplishment, and I'm sure it is quite valuable, although I personally would give up apt-get only at gun point and to call something crossplatform that only really ones on one 'platform' is silly.

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close