Shawn Walker wrote: > On Wed, May 14, 2008 at 4:52 AM, Alexander Vlasov > <[EMAIL PROTECTED]> wrote: > >> Shawn Walker wrote: >> >>> On Tue, May 13, 2008 at 9:45 AM, Alexander Vlasov >>> <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Shawn Walker wrote: >>>> >>>> >>>> >>>>> >>>>>> * Package data is therefore not a single unit - it's a bunch of >>>>>> files and metadata stored at SW repository and served by pkg.serve >>>>>> daemon. >>>>>> >>>>>> >>>>>> Problems sprouting from core issue >>>>>> >>>>>> 1. No "package file" as a container for packaged files - files >>>>>> belonging to 'package' are being stored separately on depot. >>>>>> 1. Cannot split delivery and installation process. >>>>>> 1. No offline installation. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Though the contents of a package currently has to be available from a >>>>> depot server, that does not mean that off-line installation is >>>>> impossible. >>>>> >>>>> >>>>> >>>>> >>>> Yes, Ive seen the proposal of running local depotd for this. Do you >>>> really >>>> think it's natural way of doing things? >>>> >>>> >>> That wasn't really a proposal. That was more of a prototype hack (as I >>> mentioned) that I was working on as an experiment. >>> >>> I believe it's possible to abstract the repository logic in such a way >>> that the package client can install packages from an on-disk, http, >>> ftp, smb, etc. repository. >>> >>> >> Fine. I'll be happy with this whet it will be implemented, but with >> packagefile you'll get it automatically. >> > > I disagree. I don't think you get anything automatically. > OK, we clarified that we have disagreement on this topic. > In addition, I think you're overlooking repository as tarball as a > possibility :-) > > That's a single file, but from one to many packages. > Didn't understood, sorry. >>>>>> 2. Even installer doesn't installs packages. It merely >>>>>> copies files from archive and modifying metadata to >>>>>> make everything look like installed packages. >>>>>> 1. It would be hard to create alternative >>>>>> installers (businesscard cd, netboot, >>>>>> flashdrive, etc). >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I don't make the connection between alternative installers and the >>>>> above. >>>>> >>>>> >>>>> >>>>> >>>> Separating packages installation and "system installation", e.g. >>>> partitioning, brings you an advantage: if you have to develop new >>>> installer, >>>> you should rework only relatively small piece of code. >>>> >>>> >>> That isn't a view I agree with. >>> >>> In my experience working on the bsd installer and following the >>> progress of various application installers for GNU/Linux, I've found >>> they face very similar challenges. >>> >>> >> "Application installers"? Sorry, what's this? Packages should be installed >> using package manager, and every application which requires installer is >> either broken or doesn't belong to appropriate ecosystem. >> > > You misunderstand. What I was saying is that I don't see a lot of > difference between what happens during system installation for a > single application and what happens during the installation of a > single application later on. > > The needs of the install process can be very similar between those two > scenarios. > Well, OS installation itself can be split in two big parts: everything but packages installation and packages installation. Second part is exactly the same as in regular package installation. Returning to the very first post, the point is -- if you can separate package delivery and package installation, it would be easier to introduce new installer(s), because you should only change one part out of two. >>> Actually, we're not losing that. One of the reasons why I was >>> re-working the depot to use cherrypy is that it works very well in >>> tandem with apache. >>> >>> Meaning, you can use apache's authentication mechanisms, .htaccess and >>> other things depending how you set it up. >>> >>> >> Should it be considered "hack for sort time until delivery-agnostic >> mechanism would be implemented"? >> > > Hack for sort time? I'm not sure I follow. > > Just a typo. sHort time I mean. So should it be treated as "let's use it while delivery-agnostic mechanism is in development" or "here is our new depotd, now with banana flavor and apache support?" >>> I also don't believe a particular mechanism for delivery has been >>> agreed upon yet. >>> >>> >> Oops. But the development process has been started, hasn't it? >> > > Yes, but the development process starting does not mean any decision > has been made. > > I believe it has been stated on multiple occasions that much of what > is being done is a prototype. > That's fine, it means we still can change things. >>> Yes, and those items work just as well for multiple files as they do a >>> single file. So, again, I don't see why a single file is necessary >>> >>> >> please run ls -R in depot working dir. This data representation is not >> suitable for humans. >> > > Most packaging systems, even when they have one file, are rarely > suitable for humans. > > That's why package management GUIs and CLIs exist :-) > for package-file approach, tool working with repo may not be aware of packages' structure. With current IPS approach, it should be. here is the difference. >>> Yes, but can you explain your particular view of this applies? >>> >>> >> It means you can't basically check the package unless you have put it into >> repository. Since package may contain packaging errors, it should be checked >> before releasing to public. Since package doesn't exists at all before >> pushing to repo, you should push it before any operations. >> > > Whether you're talking about a repository, a raw set of bits on disk, > or a "single package file", with the appropriate tools you can check > any of them. > Not, that's not true. In IPS, package gets some of its properties only on upload (think file...mode or dependencies). You can't build a package, check it and upload when you'll be sure everything is OK, because until you upload the package, it doesn't exists at all. >>> But they often can be the same. I also don't see the connection >>> between sustaining and build process being part of the packaging >>> system. >>> >>> >> During package life it may be rebuilt hundred times because of new versions, >> new patches, security fixes and so on. >> See http://packages.qa.debian.org/m/mysql-dfsg-5.0.html for example. >> > > Yes, but again, I don't see the connection. In other words, I don't > see the necessity of a build system being part of the packaging > system. > > As long as something has *a build system* and a way to package the > result, that's what matters. > > Whether I've built packages for RedHat, Debian, Slackware, > zeroinstall, Windows (msi), or any other os you have to have an > existing build system for the product anyway. > > If you can find some way to place a layer above the many, disparate > build systems that exist together with little effort, then I'd be > happy to see one. > > For now, I just don't think it is a problem worth solving. > Nowadays, all operating systems do work. The only thing that matters is amount of software user can get (and run). Personally I consider packaging more important than anything including kernel, because there would be much more users affected by, say, wrong firefox packaging than non-working project(4). Without proper infrastructure, packaging will be error-prone and problematic for all of us, including users, developers and administrators. > I'm far more interested in the processes that directly benefit users. > Packaging quality directly benefit users -- or make them cry. >>> I disagree. >>> >>> Developers develop software, and packaging provides a way to >>> distribute that software. >>> As for distributions having different requirements for a package, yes >>> that is sometimes true. >>> >>> However, I don't think that changes the core of the build process that >>> often -- especially when you're talking about POSIX systems. >>> At least, my build process for the projects I've worked on has been >>> the same whether it was on Solaris, FreeBSD, or GNU/Linux. >>> >>> >> Source is distribution mechanism for developers. >> > > No, source is *a* distribution mechanism for developers. It is not > *the* distribution mechanism. > Well, I think it is the way of distributing product for developers, at least in case of opensource applications. > You will find very few *successful* developers that do not *also* > distribute a binary in addition to source code. > Binaries from author are pointless. regular user should use package, enthusiast should use source. Who is responsible for security support of developer-built binary? Who tested it on particular distribution? > For closed-source projects, obviously they only distribute binaries, > thus source is not their distribution mechanism. > Even for closed-source developers, proper packaging will bring benefit of simplifying support. >> By the way, since you've mentioned you're developer, may I ask -- did you >> developed open-source application/library? And if yes, can you name it? I'm >> absolutely sure vast majority of open-source operating system use binaries >> produced and packaged by themselves, but I can't prove it until you say me >> the name))) >> > > My primary involvement in development and packaging has been with > either internal, closed applications or with "free as in beer" but not > "open source" applications. > > Every "open source" project I have been involved with distributed > binaries in some form (packages or tarballs). They also didn't always > distribute source code directly, often they placed the binaries for > download and gave information on how to get the source code out of a > repository. > > In short: > > * I don't believe that the idea of repository-as-a-package has been > explored enough. > Hm. I'm talking about package-as-a-file. > * Yet Another Build System as part of packaging isn't interesting to me. > That's sad, because it is important > * I believe *successful* developers distribute binaries as often as > they distribute source code. > > * That there are many interesting avenues left to explore in packaging. > > * If the point of ips was to simply duplicate whatever RedHat or > Debian did, what would be the point Not duplicate, but accept best practices. If you haven't noticed, linux is THE un*x-like operating system nowadays, and its ecosystem is somehow similar to jungles. Bad ideas die quickly, so after 15 years of evolving most of ideas are very reasonable, and it would be better not to duplicate efforts but to accept something that already works. Also it would minimize familiarity gap and help to increase communty
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
