[gentoo-dev] Ebuilds and the changes people make to them

[gentoo-dev] Ebuilds and the changes people make to them

[Corey Crawford]

O.K.,

I'm a huge fan of ebuilds and the whole portage system.

But: who decides what changes to make in these ebuilds? I'm really getting
sick and tired of upgrading packages only to find that someone decided to
change the ./configure options the ebuild uses.

I shouldn't have to worry about my Apache server not working after an
upgrade! This is the latest example:

The '--with-suexec-docroot' configure option for the SuExec module in
Apache2's ebuild to something other than all previous Apache2 ebuilds. This
was done in apache-2.0.48-r1. _Why?_ This broke all of the CGI scripts on my
virtual hosts until it was noticed and corrected the next day.

I shouldn't have to go into every ebuild and make sure someone didn't change
paths on me before doing (what is suppose to be) a simple upgrade.

[/rant]

Has anyone considered moving any 'configure' options to another file?

Moving the 'configure' options to another file would alleviate a lot of
problems. This would allow those of us who have working systems to continue
to have functioning systems even if the default values for those configure
options have changed.

Do-able? Comments?

---
Corey Crawford
ccrawford@seventh.net


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds and the changes people make to them

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2072 bytes --]

On Saturday 08 November 2003 21:52, Corey Crawford wrote:
> O.K.,
>
> I'm a huge fan of ebuilds and the whole portage system.
>
> But: who decides what changes to make in these ebuilds? I'm really getting
> sick and tired of upgrading packages only to find that someone decided to
> change the ./configure options the ebuild uses.
>
> I shouldn't have to worry about my Apache server not working after an
> upgrade! This is the latest example:
>
> The '--with-suexec-docroot' configure option for the SuExec module in
> Apache2's ebuild to something other than all previous Apache2 ebuilds. This
> was done in apache-2.0.48-r1. _Why?_ This broke all of the CGI scripts on
> my virtual hosts until it was noticed and corrected the next day.
>
> I shouldn't have to go into every ebuild and make sure someone didn't
> change paths on me before doing (what is suppose to be) a simple upgrade.
>
> [/rant]
[blunt reply]
On a production system one should allways read changelogs before updating, and 
possibly even first test it. Also having binary packages to put back if 
things won't work is very useful.
[/blunt reply]

> Has anyone considered moving any 'configure' options to another file?

I don't think so. It would also be complicated because sometimes configure 
scripts themselves change defaults or other packages depend on certain 
configure options being present (which makes it not optional to not use the 
option).

> Moving the 'configure' options to another file would alleviate a lot of
> problems. This would allow those of us who have working systems to continue
> to have functioning systems even if the default values for those configure
> options have changed.

I understand your problems, I agree with it, however I see no way of solving 
the problem. The best guarantee for stability is not updating unless needed, 
and in that case be very careful (a diff between the old ebuild and the new 
one).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-dev] Ebuilds and the changes people make to them

[Corey Crawford]

> -----Original Message-----
> From: Paul de Vrieze [mailto:pauldv@gentoo.org]
> Sent: Saturday, November 08, 2003 2:19 PM
> To: gentoo-dev@gentoo.org
> Subject: Re: [gentoo-dev] Ebuilds and the changes people make to them
>
> [blunt reply]
> On a production system one should allways read changelogs before
> updating, and possibly even first test it. Also having binary packages to
put back if
> things won't work is very useful.
> [/blunt reply]
>
> > Has anyone considered moving any 'configure' options to another file?
>
> I don't think so. It would also be complicated because sometimes
> configure scripts themselves change defaults or other packages depend on
certain
> configure options being present (which makes it not optional to
> not use the option).
>
> > Moving the 'configure' options to another file would alleviate a lot of
> > problems. This would allow those of us who have working systems to
continue
> > to have functioning systems even if the default values for those
configure
> > options have changed.
>
> I understand your problems, I agree with it, however I see no way
> of solving the problem. The best guarantee for stability is not updating
> unless needed, and in that case be very careful (a diff between the old
ebuild
> and the new one).
>
> Paul
>
> --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@gentoo.org
> Homepage: http://www.devrieze.net

This change was not in the ChangeLog - though I didn't diff the ebuilds
until after I had already emerged it. (Doh!)

I don't see why you couldn't have configure options in a separate file.
Sure, I understand that some configure options are required - but when you
first get the package you should get all those defaults in the separate
file. (It would be included with the ebuilds much like ChangeLog is).

Once you had those defaults you could make changes to them so that following
upgrades will use the same options. The file could actually have the values
for those configure options as variables rather than the whole
'--option=value' string. The ebuild script would then reference those
variables or use defaults if the variable isn't available in the
configuration file.

This would allow us to only specify specific things if we want (such as
paths), but use defaults for everything else.

Since this is a scripting thing, each ebuild could be modified as time went
on and wouldn't require all of them to use this system right away.

Ideally, I'd like to see something like this, using apache as an example..

 [Files]
  Configuration-apache2.defaults
  Configuration-apache2.custom
  Configuration-apache.defaults
  Configuration-apache.custom

 [In Configration-apache2.defaults]
  $DocRootPath = "/var/www/"
  $OtherVariables = ....

 [In Configuration-apache2.custom]
  $DocRootPath = "/home/www"

Since apache has two versions available to emerge, you would need two
different sets of configuration files.

Any variables in .custom would override variables defined in .defaults. If
the ebuild maintainer needs to make changes to the configure options then
he/she simply makes changes to the .defaults file, leaving any overridden
options alone in the .custom file.

Just an idea. Would make my life easier :)

---
Corey Crawford
ccrawford@seventh.net


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds and the changes people make to them

[Jeremy Maitin-Shepard]

"Corey Crawford" <ccrawford@seventh.net> writes:
> This change was not in the ChangeLog - though I didn't diff the ebuilds
> until after I had already emerged it. (Doh!)

> I don't see why you couldn't have configure options in a separate file.
> Sure, I understand that some configure options are required - but when you
> first get the package you should get all those defaults in the separate
> file. (It would be included with the ebuilds much like ChangeLog is).

> Once you had those defaults you could make changes to them so that following
> upgrades will use the same options. The file could actually have the values
> for those configure options as variables rather than the whole
> '--option=value' string. The ebuild script would then reference those
> variables or use defaults if the variable isn't available in the
> configuration file.

> This would allow us to only specify specific things if we want (such as
> paths), but use defaults for everything else.

> Since this is a scripting thing, each ebuild could be modified as time went
> on and wouldn't require all of them to use this system right away.

> Ideally, I'd like to see something like this, using apache as an example..

>  [Files]
>   Configuration-apache2.defaults
>   Configuration-apache2.custom
>   Configuration-apache.defaults
>   Configuration-apache.custom

>  [In Configration-apache2.defaults]
>   $DocRootPath = "/var/www/"
>   $OtherVariables = ....

>  [In Configuration-apache2.custom]
>   $DocRootPath = "/home/www"

> Since apache has two versions available to emerge, you would need two
> different sets of configuration files.

> Any variables in .custom would override variables defined in .defaults. If
> the ebuild maintainer needs to make changes to the configure options then
> he/she simply makes changes to the .defaults file, leaving any overridden
> options alone in the .custom file.

This seems like a matter of having (more general) package-specific
configuration files, which currently is not supported.  I would imagine
though that if such files were supported, it would make more sense for
these files to go in a sub-directory of /etc rather than in the portage
tree, since either they would be overwritten or they would have to be
excluded from rsync, which would cause problems if the package were
moved or removed.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Ebuilds and the changes people make to them

[Corey Crawford]

> -----Original Message-----
> From: Jeremy Maitin-Shepard [mailto:jbms@gentoo.org]
> Sent: Saturday, November 08, 2003 3:51 PM
> To: gentoo-dev@gentoo.org
> Subject: Re: [gentoo-dev] Ebuilds and the changes people make to them

-snip-

> This seems like a matter of having (more general) package-specific
> configuration files, which currently is not supported.  I would imagine
> though that if such files were supported, it would make more sense for
> these files to go in a sub-directory of /etc rather than in the portage
> tree, since either they would be overwritten or they would have to be
> excluded from rsync, which would cause problems if the package were
> moved or removed.
>
> --
> Jeremy Maitin-Shepard

You are right, it is a matter of having package-specific configuration
files.

However, if it's done right then packages can be moved to this system one at
a time without requiring any kind of rewrite for the portage system. Just
somewhere along the line when you did an 'emerge sync' the new ebuild file
and configuration file would be included.

The .defaults file is designed to be overwritten each time an 'emerge sync'
is done. Just like the ChangeLog file is overwritten when it's changed.

However, the .custom configuration file could easily go into an /etc
directory (with make.conf would make sense). If there is no .custom file for
the package being built (which would be checked by the package's ebuild)
then the .defaults file would provide all the configuration values the
ebuild needs.

A default .custom file does not need to be provided. The user can create
their own .custom file with the variables they want to change from the
.defaults file.

I could probably convert Apache2's ebuild file to use this system in less
than an hour.

---
Corey Crawford
ccrawford@seventh.net




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuilds and the changes people make to them

[Jeremy Maitin-Shepard]

"Corey Crawford" <ccrawford@seventh.net> writes:
[snip]
> However, if it's done right then packages can be moved to this system one at
> a time without requiring any kind of rewrite for the portage system. Just
> somewhere along the line when you did an 'emerge sync' the new ebuild file
> and configuration file would be included.

Okay.

> The .defaults file is designed to be overwritten each time an 'emerge sync'
> is done. Just like the ChangeLog file is overwritten when it's
> changed.

> However, the .custom configuration file could easily go into an /etc
> directory (with make.conf would make sense). If there is no .custom file for
> the package being built (which would be checked by the package's ebuild)
> then the .defaults file would provide all the configuration values the
> ebuild needs.

This seems reasonable.

> A default .custom file does not need to be provided. The user can create
> their own .custom file with the variables they want to change from the
> .defaults file.

> I could probably convert Apache2's ebuild file to use this system in less
> than an hour.

This system can actually, to some extent, be implemented under the
existing system in the following manner:

Rather than have a `defaults' file, the ebuild can contain the
defaults.  They would be programmed in a manner like this:

[ -z "${THE_VARIABLE}" ] && THE_VARIABLE="THE DEFAULT"

In order to avoid name clashes, however, each package-specific variable
would need to be prefixed.  For example,
APACHE2_DOCUMENT_ROOT="whatever"

Under the current system, this could be added by users to make.conf.
If package-specific configuration files were supported, the variable
could simply be named DOCUMENT_ROOT and could be specified in a
configuration file with package scope.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list