Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

From: Baptiste Daroussin <bapt_at_freebsd.org>
Date: Tue, 29 Mar 2011 20:29:39 +0000
2011/3/29 Baptiste Daroussin <bapt_at_freebsd.org>:
> 2011/3/29 Andriy Gapon <avg_at_freebsd.org>:
>> on 28/03/2011 21:22 Julien Laffaye said the following:
>>> On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper <gcooper_at_freebsd.org> wrote:
>>>>> III. Package naming that includes architecture, major OS version (for API/ABI),
>>>>> maybe more.
>>>>
>>>> This could be provided in the manifest. Doing it in the filename sort
>>>> of turns into a mess, as I've discovered working at Cisco :).
>>>>
>>>
>>> Actually, it *is* in the +MANIFEST of pkgng packages archives :-)
>>
>> Well, by the package name I meant not only a package file name.
>> Let's imagine that we do support installing i386 packages on amd64 in parallel to
>> amd64 packages.  And for some reason I want to have both 32-bit and 64-bit
>> versions of, say, firefox; e.g. for benchmarking.  If the packages would have the
>> same name, then that would be impossible.
>>
>> I think that having some thing in package name in addition to package metadata
>> could have certain benefits.
>>
>> --
>> Andriy Gapon
>>
>
> I understand but I think pkgng is already quite radical changement.
> More change is taking the risk that it would be rejected in the end,
> we still do not have any reply from portmgr, there is no insurance
> pkgng will in the end replace pkg_install. Currently pkgng requires
> only very few changes from the ports infrastruture, I don't know the
> cost of changing the name scheme.
>
> If I'm not clear enough, supporting both 32bits and 64bits packages at
> the same time on amd64 or arches that could support this kind of
> installation, is a large change we don't want to take the
> responsability of :) and implementing this in pkgng would significate
> we already choose how it should work.
>
> regards,
> Bapt
>

seems it was not clear :)

ok let's try to say it simpler :) the main goal is to keep it simple
for now, simple and rock solid, so that we can replace pkg_install and
do some cleanup in the ports tree, add the "must have" features while
doing that. And only when we will be ready for that and that portmgr
have decided that it is mature enough to replace pkg_install, only
after that we will start improving with new features and new changes.

I thinks changing the package name scheme is not a "must have"
feature, it for sure is and intresting feature, but what about pushing
to after the first stable release? managing architecture as we plan to
do it is enough imho.

But I can be wrong.

regards,
Bapt
Received on Tue Mar 29 2011 - 18:30:00 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:12 UTC