Shawn Walker wrote:
> On Wed, May 14, 2008 at 12:27 PM, Alexander Vlasov
> <[EMAIL PROTECTED]> wrote:
>
>> (sorry for overquoting, but seems it matters in this thread)
>>
>> Shawn Walker wrote:
>>
>>> On Wed, May 14, 2008 at 10:22 AM, Alexander Vlasov
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> Shawn Walker wrote:
>>>> 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.
>>>>
>>>>
>>> I don't disagree with that. That's why I'm interested in distributing
>>> mini-repositories as the delivery format.
>>>
>>>
>> Oh god. Finally I got your idea about micro-repos. It sounds like big
>> improvement over current ips approach, but comparing (ips+minirepo) vs.
>> traditional package-as-file, I'm still not sure that new approach is better.
>> We're losing per-package granularity, but I can't see what we're getting.
>>
>
> You don't really lose per-package granularity in the strictest sense.
>
> In other words, there's no reason why a mini-repository can't contain
> a single package.
>
> There's a few things that distributing a repository instead of a
> package solves in my mind:
>
> * Finding satisfiable dependencies
> * Avoiding package format issues
> * Ease of serving packages via almost any protocol
>
> My personal, eventual goal is to create a prototype that lets you have
> nothing but the files for the repository sitting *somewhere* (think
> /var/my_repository, or http://host.name/repository) and the client
> would be smart enough to grab everything from the server and install
> it without any special software required on the "server-side".
>
> For example, I would love to see:
>
> pkg -d /var/repo_dir install SUNWfirefox
>
> or
>
> pkg -d http://random.akamai.cache.server/repo_dir install SUNWfirefox
>
> ...and have it grab everything it needs from the indicated location.
>
> Likewise this would allow you to put a collection of say, network
> drivers, on a USB flash device and you could do:
>
> pkg -d /media/flash_device list -sa
>
> To see all the available packages, their versions, etc.
>
> Or you could easily do:
>
> pkg -d /media/flash_device search file_to_look_for
>
> Something like that anyway.
>
> To me, that is a marked advantage over the current process today where
> a user downloads several packages files into a directory like this:
>
> neatprogram.pkg, baz.pkg, bar.pkg, foo.pkg
>
> Then they're left to figure out how to get that to install.
>
> With many systems, they also have very limited query or other
> capabilities until they install the package.
>
> So having a "repository" of neatprogram, baz, bar, and foo could
> provide a lot of nice additional functionality.
>
> I believe it would even be possible to have:
>
> my_repo_tarball.tgz
>
> pkg -d /path/to/my_repo_tarball.tgz install SUNWfirefox
>
> ...and have it automatically handle the rest.
>
All of these issues are already solved for ages, you're knocking at open
door. There are apt (for both deb and rpm), aptitude (deb), yum(rpm),
urpmi(rpm) and maybe some other tools which
* separate delivery from installation
* allow user to have different delivery techniques (including even
bittorrent!)
* satisfy dependencies
* do not require any specific server-side software (http daemon, ftp
daemon or just a package accessible via filesystem are ok)
* and has many other nice abilities.
In linux world, nobody is installing or satisfying dependencies by hands
for ages.
>>> If you're applying all of this to "things as they currently are", yes
>>> I'd agree to a certain extent.
>>>
>>>
>>>
>> I have no tools but those which do exist right now. So either current tools
>> should be good or there should be a clear goal to design and implement other
>> set of tools, IMHO.
>>
>
> There are lots of entries in Bugzilla about meeting various needs. I'd
> encourage you to file enhancement requests for any of the gaps.
>
>
>>> I don't disagree that packaging is important, but I still don't see
>>> the necessity of the build system being part of packaging.
>>>
>>>
>>>
>> If we're talking about package build system (not binaries build system), it
>> should be a part od packaging system because it does two-step transformation
>> source code -> binaries -> correct package. First step is
>> application-specific, second one can be reasonably general and
>> contet-agnostic. I'm talking about second one.
>> It is only related to the packaging system.
>>
>
> If you're just talking about a way to re-arrange the binaries into a
> format for a package, that's what the depot server does right now if I
> understand you correctly.
>
No it does not. It's being done manually right now (for native packages)
or by converting existing svr4 package into ips (in this case packaging
is beyond the scope)
> In that case, I think I could still apply my personal idea of being
> able to create mini-repositories easily to do that.
>
>
>>> Having a build system being part of the packaging system is not a
>>> guarantee of the resulting package quality, nor does it in my view,
>>> greatly benefit packaging quality.
>>>
>>>
>> Unified process will 1) reduce the amount of dummy mistakes 2) make fixing
>> process much easier (just modify what needs to be modified and rebuilt your
>> package with one command)
>>
>
> It depends on which build system you are talking about. Compiling or
> creating packages?
>
I'm only talking about creating packages. Different pieces of software
has different compiling techniques, and we obviously should be able to
package software regardless of binary-build system it uses. Sorry if I
didn't clarified it from the very beginning.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
