freebsd stable - Sep 2014 - [HEADSUP] pkg(8) is now the only package management tool

Garrett Cooper wrote:
>> On Sep 2, 2014, at 4:47, Michelle Sullivan <michelle at
sorbs.net> wrote:
>>
>> Marcus von Appen wrote:
>>     
>>> Alban Hertroys <haramrae at gmail.com>:
>>>
>>>       
>>>> I can totally understand that at some point it starts to get
>>>> impossible to maintain two separate packaging systems and I
understand
>>>> that you think 2 years is enough time to shake things out, but
>>>> software vendors aren't that quick. For many, 2 years is a
short time.
>>>>         
>>> It also should be noted that everyone had enough time to raise
those
>>> issues
>>> in the time between tthe announcement and now. No one did. Now that
it is
>>> gone, they are brought up, while they should have been long time
ago
>>> instead. It can't work that way.
>>>
>>> My 2 cents in this discussion :-).
>>>       
>> Actually I brought it up as soon as I found the EOL was a deadline for
>> breaking pkg_* tools, was told, "too late now" - that was
more than 2
>> weeks ago, less than 2 months ago (forget the date) ... I'm happy
with
>> an EOL and working to upgrade everything, I'm not happy that the
EOL was
>> not actually an EOL and it was actually a deadline.
>>     
>
> Hi Michelle,
>     One subtle point that I wanted to ask for clarification is you thought
the EOL announcement for pkg_install was going to be "pkg_install is no
longer going to be supported, but you can still use it", instead of
"pkg_install support is going to be removed from the tree" -- is that
correct?
>   
100% correct! (thank you for being one of the few to see the subtle but
*very* important difference)
>     You'd probably hate to do this, but forking the sources and
changing from portsnap to a git or svn backed ports tree that downloads a
tarball snapshot might be the best resolution to this issue now...
>   
This is my only option - however, I suspect I'm already f**ked - my
build servers kicked off at 4am and the non pkg jails automatically
converted themselves to pkg.. the pkg jails obviously continued...
however I now have a repo that contains half pkg versions in the same
directory structure and indexes as the pkg_install structure...

Time to rebuild everything from scratch I think - second time in a
year.. I'm guessing my boss is going to tell me, use RPM, no wasting
more time on it... only time will tell... you'll know the result if you
see future posts and patches from me.

Michelle

-- 
Michelle Sullivan
http://www.mhix.org/

On Tue, Sep 2, 2014 at 11:40 AM, Michelle Sullivan <michelle at sorbs.net>
wrote:
> This is my only option - however, I suspect I'm already f**ked - my
> build servers kicked off at 4am and the non pkg jails automatically
> converted themselves to pkg.. the pkg jails obviously continued...
> however I now have a repo that contains half pkg versions in the same
> directory structure and indexes as the pkg_install structure...
>
So, the flip side of enterprise software management is that you probably
should not be integrating a rolling release like ports into what is
supposed to be a stable verified environment in the first place.
*Especially* not via cron jobs with no supervision. At the very least, your
jails should be working from a local ports tree (or packages via
poudriere), with cherry-picking of locally tested patches.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at
sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

Brandon Allbery wrote:
> On Tue, Sep 2, 2014 at 11:40 AM, Michelle Sullivan
<michelle@sorbs.net>
> wrote:
>
>   
>> This is my only option - however, I suspect I'm already f**ked - my
>> build servers kicked off at 4am and the non pkg jails automatically
>> converted themselves to pkg.. the pkg jails obviously continued...
>> however I now have a repo that contains half pkg versions in the same
>> directory structure and indexes as the pkg_install structure...
>>
>>     
>
> So, the flip side of enterprise software management is that you probably
> should not be integrating a rolling release like ports into what is
> supposed to be a stable verified environment in the first place.
> *Especially* not via cron jobs with no supervision. At the very least, your
> jails should be working from a local ports tree (or packages via
> poudriere), with cherry-picking of locally tested patches.
>
>   
The roll until they get a stable base (using Jenkins as the controller)
- they've been rolling since a patch to DBIx-SearchBuilder (that I
created and submitted), which out came the DBD::Pg update to 3.3.0 and
the subsequent blacklisting of it for RT 4.x and then the tcl breakage
around mid August until 2 days ago...  So yeah not that stupid.

-- 
Michelle Sullivan
http://www.mhix.org/

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"

On 02.09.14 18:40, Michelle Sullivan wrote:
> Time to rebuild everything from scratch I think - second time in a 
> year.. I'm guessing my boss is going to tell me, use RPM, no wasting 
> more time on it... only time will tell... you'll know the result if 
> you see future posts and patches from me. 
You must really hate RPM, as pkg is trying to do essentially the same 
for FreeBSD. :)

As others already mentioned, rebuilding production environments/packages 
via cron jobs from moving target such as the current ports three is not 
the best setup favoring 'stability'. These things can and do fail 
sometimes. From your postings on this thread I understand you are 
unhappy that your pkg_tools poudriere jails were messed up. So are many 
others.

The switch is indeed a pain, but the direction is good. Progress is part 
of evolution -- it knocks off some, and promotes others. We will have to 
live with it. WhateverHat is not better.

Daniel