openbsdbinpatch-misc

[Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

Hey.

Glad to see binpatch under the light again.

To follow the todo thread, interesting features could be:

- no need to install the sets, use mtree (drawback, make the patches 
bigger), so anyone with a stable system and /usr/src can create binpatches
- small app to install/remove patches and of course, list them (patch_add, 
patch_delete, patch_info...)
- when it is "perfect", force someone to import it in the official cvs ;-)

Cheers!

-- 
Antoine

Re: [Openbsdbinpatch-misc] hello list

[<ger...@gm...>]

2007/1/9, Antoine Jacoutot <aja...@lp...>:
> Hey.
>
> Glad to see binpatch under the light again.

Hey Antoine :-)  thanks for coming.

>
> To follow the todo thread, interesting features could be:
>
> - no need to install the sets, use mtree (drawback, make the patches
> bigger), so anyone with a stable system and /usr/src can create binpatches

I'm not sure about this. I'd like to hear opinions of the other
members of the list.

As much as I agree that it would be a convenience to get a way to use
mtree and so avoid installing the sets (it would be faster and require
less disk space), I think binpatch would not make sense anymore if we
pack files others than the modified ones.

Or am I missing something?

What others think about this?


> - small app to install/remove patches and of course, list them (patch_add,
> patch_delete, patch_info...)

I would be glad to add it. I'd like some enlightenment here too,
please. I remember that some people (like me) is unable to see why a
patch would be uninstalled. If the patch was incorrect, patch again.

I'd like to keep binpatch's approach as simple as possible. I like to
think of a binary patch as a simple tarball to unpack on / as opposed
to Solaris's patch dependencies and special programs to handle it.

But I am open and would love to read others' opinions and prove me
wrong if I am. Really.


> - when it is "perfect", force someone to import it in the official cvs ;-)

;-)

-- 
Gerardo Santana

Re: [Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

On Wed, 10 Jan 2007, Gerardo Santana G=F3mez Garrido wrote:
> As much as I agree that it would be a convenience to get a way to use
> mtree and so avoid installing the sets (it would be faster and require
> less disk space), I think binpatch would not make sense anymore if we
> pack files others than the modified ones.

Well it would still make sense as even if there're a bit bigger than the=20
ones actually built that wouldn't change anything about binpatches=20
greatness ;-)

I just find it more convenient not to have to unpack all sets... but well=
,=20
that's just me!

> I would be glad to add it. I'd like some enlightenment here too,
> please. I remember that some people (like me) is unable to see why a
> patch would be uninstalled. If the patch was incorrect, patch again.

Totally agree.

> I'd like to keep binpatch's approach as simple as possible. I like to
> think of a binary patch as a simple tarball to unpack on / as opposed
> to Solaris's patch dependencies and special programs to handle it.

I think a small patch_add and patch_info (or patch_list or whatever) woul=
d=20
be nice and easy to do.
patch_delete is not needed indeed.

--=20
Antoine

Re: [Openbsdbinpatch-misc] hello list

[Ingo S. <sch...@us...>]

Hi Gerardo, salut Antoine,

Gerardo Santana Gómez Garrido wrote on Wed, Jan 10, 2007:
> 2007/1/9, Antoine Jacoutot <aja...@lp...>:

>> - no need to install the sets, use mtree (drawback, make the
>>   patches bigger), so anyone with a stable system and /usr/src
>>   can create binpatches
> 
> I'm not sure about this.  I'd like to hear opinions of the other
> members of the list.

Usually, i hate options (in particular useless and complicated ones).
In this case, an option might make sense, though.

Both types of patches have their relevant advantage:
Using mtree doesn't require getting and unpacking install sets.
Using the install sets minimizes patch size.

Besides, the effect of this option will be strictly local
at a single point inside the bsd.binpatch.mk file, so the
resulting obfuscation will be minimal.

I suggest to keep the variant using the install sets as the
default.  Usually, you do have the install sets (otherwise, how
did you install the OS in the first place?), and usually, the
machine used for building binpatches will not be short on
resources (rather, the machine the binpatches are built for
might be a small or slow one).

> As much as I agree that it would be a convenience to get a way
> to use mtree and so avoid installing the sets (it would be faster
> and require less disk space), I think binpatch would not make
> sense anymore if we pack files others than the modified ones.
> 
> Or am I missing something?

Building an mtree-style binpatch is even simpler than building
a standard binpatch.  Installing an mtree-style binpatch requires
only a little more resources than installing a standard binpatch -
yet, compared to the standard solution make release(8), it is
still *much* less demanding.  Thus, no, i do not think Antoine's
suggestion would render binpatch useless.

On the other hand, it would be a pity if the possibility to
minimize patch size were given up completely.

[...]
> I'd like to keep binpatch's approach as simple as possible.

I do strongly agree.

Yours,
  Ingo

Re: [Openbsdbinpatch-misc] hello list

[z0mbix <zo...@zo...>]

On 10/01/07, Ingo Schwarze <sch...@us...> wrote:
> Hi Gerardo, salut Antoine,
>
> Gerardo Santana G=F3mez Garrido wrote on Wed, Jan 10, 2007:
> > 2007/1/9, Antoine Jacoutot <aja...@lp...>:
>
> >> - no need to install the sets, use mtree (drawback, make the
> >>   patches bigger), so anyone with a stable system and /usr/src
> >>   can create binpatches
> >
> > I'm not sure about this.  I'd like to hear opinions of the other
> > members of the list.
>
> Usually, i hate options (in particular useless and complicated ones).
> In this case, an option might make sense, though.
>
> Both types of patches have their relevant advantage:
> Using mtree doesn't require getting and unpacking install sets.
> Using the install sets minimizes patch size.
>
> Besides, the effect of this option will be strictly local
> at a single point inside the bsd.binpatch.mk file, so the
> resulting obfuscation will be minimal.
>
> I suggest to keep the variant using the install sets as the
> default.  Usually, you do have the install sets (otherwise, how
> did you install the OS in the first place?), and usually, the
> machine used for building binpatches will not be short on
> resources (rather, the machine the binpatches are built for
> might be a small or slow one).
>
> > As much as I agree that it would be a convenience to get a way
> > to use mtree and so avoid installing the sets (it would be faster
> > and require less disk space), I think binpatch would not make
> > sense anymore if we pack files others than the modified ones.
> >
> > Or am I missing something?
>
> Building an mtree-style binpatch is even simpler than building
> a standard binpatch.  Installing an mtree-style binpatch requires
> only a little more resources than installing a standard binpatch -
> yet, compared to the standard solution make release(8), it is
> still *much* less demanding.  Thus, no, i do not think Antoine's
> suggestion would render binpatch useless.
>
> On the other hand, it would be a pity if the possibility to
> minimize patch size were given up completely.
>
> [...]
> > I'd like to keep binpatch's approach as simple as possible.
>
> I do strongly agree.
>
> Yours,
>   Ingo
>

I'm happy with the way binpatch is, nice and simple. As previously
stated above, most people have the install sets to hand on the build
server anyway so I see no need to change things. I have been using
binpatch for a couple of years now with great success. Here are my
patch_add and patch_info that I use to manage my binpatches:

http://www.zombix.org/code/patch_add
http://www.zombix.org/code/patch_info

Cheers z0mbix

Re: [Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

On Wed, 10 Jan 2007, z0mbix wrote:
> http://www.zombix.org/code/patch_add
> http://www.zombix.org/code/patch_info

Error 404

-- 
Antoine

Re: [Openbsdbinpatch-misc] hello list

[z0mbix <zo...@zo...>]

Sorry, try now. dyndns not working for some reason.

On 11/01/07, Antoine Jacoutot <aja...@lp...> wrote:
> On Wed, 10 Jan 2007, z0mbix wrote:
> > http://www.zombix.org/code/patch_add
> > http://www.zombix.org/code/patch_info
>
> Error 404
>
> --
> Antoine
>

Re: [Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

On Thu, 11 Jan 2007, z0mbix wrote:
> Sorry, try now. dyndns not working for some reason.

They look simple, which is good.
AFAIK, I think this is an exemple of what should be after.

-- 
Antoine

Re: [Openbsdbinpatch-misc] hello list

[<ger...@gm...>]

2007/1/11, Antoine Jacoutot <aja...@lp...>:
> On Thu, 11 Jan 2007, z0mbix wrote:
> > Sorry, try now. dyndns not working for some reason.
>
> They look simple, which is good.
> AFAIK, I think this is an exemple of what should be after.

Indeed. I like them. I have read them many times and haven't found
anything I'd like to change so far.

They can be enriched though if someone else has another idea/script.

Otherwise, I'd like to have your permission z0mbix to add them to the
binpatch distribution.

-- 
Gerardo

Re: [Openbsdbinpatch-misc] hello list

[z0mbix <zo...@zo...>]

yes ofcourse, go for it. There's probably alot more that can be added,
but I don't really see the point, there's some simple error checking.
Maybe something a little more intelligent when it comes to replacing
kernels.

Cheers z0mbix

On 11/01/07, Gerardo Santana G=F3mez Garrido <ger...@gm...> wr=
ote:
> 2007/1/11, Antoine Jacoutot <aja...@lp...>:
> > On Thu, 11 Jan 2007, z0mbix wrote:
> > > Sorry, try now. dyndns not working for some reason.
> >
> > They look simple, which is good.
> > AFAIK, I think this is an exemple of what should be after.
>
> Indeed. I like them. I have read them many times and haven't found
> anything I'd like to change so far.
>
> They can be enriched though if someone else has another idea/script.
>
> Otherwise, I'd like to have your permission z0mbix to add them to the
> binpatch distribution.
>
> --
> Gerardo
>

Re: [Openbsdbinpatch-misc] hello list

[Mike E. <mi...@er...>]

Gerardo Santana G=F3mez Garrido wrote:
> Indeed. I like them. I have read them many times and haven't found
> anything I'd like to change so far.
>=20
> They can be enriched though if someone else has another idea/script.
>=20
> Otherwise, I'd like to have your permission z0mbix to add them to the
> binpatch distribution.

What might be a good idea is creating two ports or a binpatch port with a=
=20
binpatch-build multi-package.  The binpatch port installed scripts like z=
0mbix's=20
with a /usr/local/share/examples/binpatch/binpatch.conf (@sample'd to=20
/etc/binpatch.conf) with a mirror list (which I, for instance, would modi=
fy to=20
point to my local mirror of binpatches or it could point to, like,=20
http://erdelynet.com/downloads/4.0/).

Then, most users could install the "binpatch" package to install binpatch=
es made=20
and stored on a local mirror.  The build box could have the binpatch-buil=
d and=20
binpatch packages installed to build binpatches.

Just thinking out loud.

Also, I made patches for binpatch (which I will send in a couple minutes)=
 that=20
creates a package list and stores it in /var/db/binpatch at the patch cre=
ation=20
point (stored in the tarball).  z0mbix's scripts could be modified to use=
 that=20
information.

-ME

Re: [Openbsdbinpatch-misc] hello list

[<ger...@gm...>]

2007/1/11, Mike Erdely <mi...@er...>:
> Gerardo Santana G=F3mez Garrido wrote:
> > Indeed. I like them. I have read them many times and haven't found
> > anything I'd like to change so far.
> >
> > They can be enriched though if someone else has another idea/script.
> >
> > Otherwise, I'd like to have your permission z0mbix to add them to the
> > binpatch distribution.
>
> What might be a good idea is creating two ports or a binpatch port with a
> binpatch-build multi-package.  The binpatch port installed scripts like z=
0mbix's
> with a /usr/local/share/examples/binpatch/binpatch.conf (@sample'd to
> /etc/binpatch.conf) with a mirror list (which I, for instance, would modi=
fy to
> point to my local mirror of binpatches or it could point to, like,
> http://erdelynet.com/downloads/4.0/).

Aha, and/or BINPATCH_PATH, similar to PKG_PATH.

>
> Then, most users could install the "binpatch" package to install binpatch=
es made
> and stored on a local mirror.  The build box could have the binpatch-buil=
d and
> binpatch packages installed to build binpatches.
>
> Just thinking out loud.

Sounds good.

--=20
Gerardo Santana

Re: [Openbsdbinpatch-misc] hello list

[z0mbix <zo...@zo...>]

On 12/01/07, Gerardo Santana G=F3mez Garrido <ger...@gm...> wr=
ote:
> 2007/1/11, Mike Erdely <mi...@er...>:
> > Gerardo Santana G=F3mez Garrido wrote:
> > > Indeed. I like them. I have read them many times and haven't found
> > > anything I'd like to change so far.
> > >
> > > They can be enriched though if someone else has another idea/script.
> > >
> > > Otherwise, I'd like to have your permission z0mbix to add them to the
> > > binpatch distribution.
> >
> > What might be a good idea is creating two ports or a binpatch port with=
 a
> > binpatch-build multi-package.  The binpatch port installed scripts like=
 z0mbix's
> > with a /usr/local/share/examples/binpatch/binpatch.conf (@sample'd to
> > /etc/binpatch.conf) with a mirror list (which I, for instance, would mo=
dify to
> > point to my local mirror of binpatches or it could point to, like,
> > http://erdelynet.com/downloads/4.0/).
>
> Aha, and/or BINPATCH_PATH, similar to PKG_PATH.
>

All these are great ideas, I now have around 6 OpenBSD servers at work
and 2 at home. It's getting a bit of a pain to manually pull these
packages down for each update. This would save me quite a bit of time
already and I don't have a particularly large OpenBSD network.

I'll see what I can add to patch_add to enable this functionality.
What other functionality do you think we need? md5sum/sha1 checksums?

Cheers z0mbix

Re: [Openbsdbinpatch-misc] hello list

[Mike E. <mi...@er...>]

z0mbix wrote:
> I'll see what I can add to patch_add to enable this functionality.
> What other functionality do you think we need? md5sum/sha1 checksums?

A recent patch to bsd.binpatch.mk includes the ability to use gzsig to sign 
packages.  Maybe you should include the ability to verify that signature.

> Cheers z0mbix

-ME