[gentoo-portage-dev] Conary

[gentoo-portage-dev] Conary

[andrea ferraris]

Hi all!

This one will be my first msg to the list and maybe also
the last one.
I'm not a portage developer, neither a free software
developer, maybe a sysadm, fallen in love of Linux more
than 10 years ago; it was 1.0 kernel and Slackware.

Now, after many years of RedHat, some Mandrake's and
SUSE's usage and Debian too (few, very few because their
installer was really worst than the Gentoo one and I'm not
joking), it's about a year that I'm using Gentoo with big
satisfaction.
It's really a great - for me the greatest - distribution
and its philosophy (a meta-distribution where the focus is
on the user's freedom) is the best one for me, but I think
also in the true Linux spirit (the free software of the
excellence).
One of the reasons to choose Gentoo has been portage, its
power and its flexibility. I think it's really better (in a
objective manner) than rpm or dpkg and it can solve problems
they can't address.
Many years ago I went away from Slackware to RedHat because
rpm was really better than tgz to manage packages,
dependencies, installations, uninstallations and upgrades,
like in these days I think portage is better than rpm and
dpkg.

Now I found on the lwn.net (Linux Weekly News) of thursday,
Oct 14, an article on Conary. From its home page
http://www.specifix.com/technology/index.htm it is:

"a distributed software management system for Linux
distributions. It replaces traditional package mangement
solutions (such as RPM and dpkg) with one designed to
enable loose collaboration across the Internet.
Conary enables sets of distributed and loosely connected
repositories to define the components which are installed
on a Linux system. Rather than having a full distribution
come from a single vendor, Conary allows administrators
and developers to branch a distribution, keeping the
pieces which fit their environment while grabbing components
from other repositories across the Internet.
[...]
complete information on Conary is available from the
Conary Wiki <http://wiki.specifixinc.com>.
It includes links to white papers, technical papers,
documentation, and source code. It also provides information
on Specifix's Linux distribution which was built using
Conary."

I'd ask you, who can develop and developped that superb thing
that's portage to see if there are - and I think that yes,
there are - usefull concepts, idea and code to grab from there
to make yet better portage.

In my Gentoo system administration experience there are at
least 2-3 things that with a Conary sw management system
could address better than portage. It is local configuration
files updates, binary only updates and updates of the only
changed things, instead of full ones.
The first one is simple: in a litle gentoo system that I'm
managing for a year now with authomatic nightly updates,
I had to update almost manually about a hundred of
configuration files. The system (gentoo) is well designed,
so, if I didn't update, all works because the original
configuration files stay in place, but for the better and
also only for the good, the thing to do is to use etc-update
to update such configuration files. The problem is that such
process is really time consuming and error prone, so it's
not very good.
Instead it seems that, from the architecture level, Conary
has been made to manage local configuration changes an
updates to avoid such pains.
The second thing is the binary choice. In Gentoo is more
difficult than it should be (at least from my point ov view),
it is that the system gives the choice of binary updates only,
but it's really difficult to find only binary packages and
also if one can find them it's impossible to find only
modified files in a package and to update only those and also
to download only diffs and only binaries diffs. I think that
also these things could be achieved studying the Conary
way.

Sorry for the length of the message and for the absence
of code, practical idea or implementations.
I'm sorry, but I can't.

Best regards, good gentooing to all and yet better
portageing to you,

Andrea

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 3291 bytes --]

On Thursday 21 October 2004 00:02, andrea ferraris wrote:
> The first one is simple: in a litle gentoo system that I'm
> managing for a year now with authomatic nightly updates,
> I had to update almost manually about a hundred of
> configuration files. The system (gentoo) is well designed,
> so, if I didn't update, all works because the original
> configuration files stay in place, but for the better and
> also only for the good, the thing to do is to use etc-update
> to update such configuration files. The problem is that such
> process is really time consuming and error prone, so it's
> not very good.

You might want to try dispatch-conf. It is superior to etc-update in many 
aspects, and it comes with gentoolkit. Further there is normally no need 
to update every night. While there is no problem with it, it will 
increase the maintenance load unnecessarilly.

> The second thing is the binary choice. In Gentoo is more
> difficult than it should be (at least from my point ov view),
> it is that the system gives the choice of binary updates only,
> but it's really difficult to find only binary packages and
> also if one can find them it's impossible to find only
> modified files in a package and to update only those and also
> to download only diffs and only binaries diffs. I think that
> also these things could be achieved studying the Conary
> way.

The thing is that portage's binary packages are far from perfect when 
compared for example with rpm's. The problem is caused by the fact that 
two seemingly similar binary packages can be different to the extend that 
one will work on your system and the other not. As gentoo is mainly a 
source distribution the effort required to make binaries "better" is 
probably too big. Even then all kinds of binary problems are unavoidable 
and the main cause of releases in all binary distributions, even debian. 
With source one can mix and match, with binary releases one must ensure 
that all dependencies are completely compatible with the versions that 
existed when the package was built.

> Sorry for the length of the message and for the absence
> of code, practical idea or implementations.
> I'm sorry, but I can't.

Idea's rule.

On the point of not having a central tree. That is basically a support 
nightmare waiting to happen. In gentoo we have allready problems with 
supporting users that make improper local modifications or use some 
packages from breakmygentoo.net (allthough they seem to have adopted a 
minimum level of quality too). The problem is that as systems get more 
and more dissimilar, problems get harder and harder to reproduce. One can 
also not as a volunteer set up a configuration that is similar to a user 
just for fixing one bug.

As for keeping local changes, that is certainly possible now with gentoo. 
It is fairly easy to set up, allthough not officially supported or 
documented. The concept of overlays is well supported, and probably most 
developers use it for a few of their own packages. Supporting an 
organizational tree is fairly easy too, all required is some hard disk 
space and an rsync server.

Paul

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

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

Re: [gentoo-portage-dev] Conary

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

On Thu, Oct 21, 2004 at 10:30:21AM +0200, Paul de Vrieze wrote:
> You might want to try dispatch-conf. It is superior to etc-update in many 
> aspects, and it comes with gentoolkit. Further there is normally no need 
> to update every night. While there is no problem with it, it will 
> increase the maintenance load unnecessarilly.

Actually it's part of Portage (at least until .51_rc9), but that's
nitpicking :)

> The thing is that portage's binary packages are far from perfect when 
> compared for example with rpm's. The problem is caused by the fact that 
> two seemingly similar binary packages can be different to the extend that 
> one will work on your system and the other not. As gentoo is mainly a 
> source distribution the effort required to make binaries "better" is 
> probably too big. Even then all kinds of binary problems are unavoidable 
> and the main cause of releases in all binary distributions, even debian. 
> With source one can mix and match, with binary releases one must ensure 
> that all dependencies are completely compatible with the versions that 
> existed when the package was built.

Some issues with binary releases are covered by a document that rac has on
his dev page. It's not the official Gentoo policy, but it does make you
think about it :)

http://dev.gentoo.org/~rac/binaries.html

Just a complementary note.

Wkr,
      Sven Vermeulen

-- 
  Documentation & PR project leader

  The Gentoo Project   <<< http://www.gentoo.org >>>

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

Re: [gentoo-portage-dev] Conary

[Roman Gaufman]

On Thu, 21 Oct 2004 11:52:16 +0200, Sven Vermeulen <swift@gentoo.org> wrote:
> Actually it's part of Portage (at least until .51_rc9), but that's
> nitpicking :)
yup:
server / # qpkg -f /usr/sbin/dispatch-conf
sys-apps/portage *

What do you mean until .51_rc9? -- will it be included in .51?
There's no way in hell I'm moving back to etc-update -- and frankly, I
dont see how anyone can tolerate it :)

> Some issues with binary releases are covered by a document that rac has on
> his dev page. It's not the official Gentoo policy, but it does make you
> think about it :)
> 
> http://dev.gentoo.org/~rac/binaries.html
Personally, I find binary packages on gentoo perfect for my use. I
have several computers on the network, all running gentoo with no gcc
or any header files. I then have an offline machine that gets
everything compiled and put on a shared /usr/portage for all the
machines to just emerge -k simultaneously.

That way when I emerge something, I can review the config files, add
some custom options and some fancy polish and quickpkg will bundle
everything together all pre-configured.

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Thu, Oct 21, 2004 at 11:46:14AM +0000, Roman Gaufman wrote:
> On Thu, 21 Oct 2004 11:52:16 +0200, Sven Vermeulen <swift@gentoo.org> wrote:
> What do you mean until .51_rc9? -- will it be included in .51?
> There's no way in hell I'm moving back to etc-update -- and frankly, I
> dont see how anyone can tolerate it :)

No, sorry for the confusion. What I meant was that I currently still have
_rc9 on my system so _if_ for some obscure reason dispatch-conf _would have
been moved_ to gentoolkit afterwards I wouldn't know it.

But that's not the case.

Wkr,
      Sven Vermeulen
      
-- 
  Documentation & PR project leader

  The Gentoo Project   <<< http://www.gentoo.org >>>

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

Re: [gentoo-portage-dev] Conary

[Roman Gaufman]

Ah, good. You got me scared for a second. It does however make sense
for it to be removed. Many dispatch-conf bugs are left untouched for
months since the dev that wrote it disappeared without notice.

Maybe if I post some patches they'll be commited, but seems anything
dispatch-conf related is halted at the moment.

On Thu, 21 Oct 2004 14:44:35 +0200, Sven Vermeulen <swift@gentoo.org> wrote:
> On Thu, Oct 21, 2004 at 11:46:14AM +0000, Roman Gaufman wrote:
> > On Thu, 21 Oct 2004 11:52:16 +0200, Sven Vermeulen <swift@gentoo.org> wrote:
> > What do you mean until .51_rc9? -- will it be included in .51?
> > There's no way in hell I'm moving back to etc-update -- and frankly, I
> > dont see how anyone can tolerate it :)
> 
> No, sorry for the confusion. What I meant was that I currently still have
> _rc9 on my system so _if_ for some obscure reason dispatch-conf _would have
> been moved_ to gentoolkit afterwards I wouldn't know it.
> 
> But that's not the case.
> 
> 
> 
> Wkr,
>       Sven Vermeulen
> 
> --
>   Documentation & PR project leader
> 
>   The Gentoo Project   <<< http://www.gentoo.org >>>
> 
> 
>

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Jason Stubbs]

On Thursday 21 October 2004 22:20, Roman Gaufman wrote:
> Ah, good. You got me scared for a second. It does however make sense
> for it to be removed. Many dispatch-conf bugs are left untouched for
> months since the dev that wrote it disappeared without notice.
>
> Maybe if I post some patches they'll be commited, but seems anything
> dispatch-conf related is halted at the moment.

There's a lot of patches sitting in bugs already. It's just kind of hard to 
find them. However, I'd be happy to review and if pointed to them. :)

Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[andrea ferraris]

Roman Gaufman wrote:

> Personally, I find binary packages on gentoo perfect for my use. I
> have several computers on the network, all running gentoo with no gcc
> or any header files. I then have an offline machine that gets
> everything compiled and put on a shared /usr/portage for all the
> machines to just emerge -k simultaneously.
> 
> That way when I emerge something, I can review the config files, add
> some custom options and some fancy polish and quickpkg will bundle
> everything together all pre-configured.

You're a very patient person, or your offline machine is at least
a 4 3Ghz Xeon with 4 GB RAM, or you never compiled something like
X and/or OpenOffice  and some other nice little things ;-) .
It is that what you're describing is a lucky, but I fear uncommon, 
situation: you can afford a plus machine and you don't have different 
machines and machines types to compile for. I think that a common 
situation, with different machines and machine types and production 
machines, require a big overhead either in CPU load, either to schedule, 
monitor and manage the compilations for not suffering for such CPU load 
increase.
I made what you're describing, but also in my case, with the same 
machines and machine types and the CPU load increase was not a concern.
I think that in most cases, with a smart monitoring, scheduling and 
managing and with ccache and distcc you can get the target also in more 
common situations without performance degradation in the business 
services offered by the machines, but there are concerns either for 
security (gcc installed everywhere to have distcc working) and the work 
for managing monitoring, scheduling and control the CPU load and network 
traffic increase.

Sorry for the beastly English, but I can write a worst French and also a 
very bad Italian ;-)

Andrea

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Roman Gaufman]

On Sun, 24 Oct 2004 19:44:32 +0200, andrea ferraris
<andrea_ferraris@libero.it> wrote:
> You're a very patient person, or your offline machine is at least
> a 4 3Ghz Xeon with 4 GB RAM, or you never compiled something like
> X and/or OpenOffice  and some other nice little things ;-) .

800mhz with 256Mb ram -- why do I need a 100% up to date system? -- so
X takes about 4 hours to compile, so what? -- what difference does it
make?

> It is that what you're describing is a lucky, but I fear uncommon,
> situation: you can afford a plus machine and you don't have different
> machines and machines types to compile for.

First of all, you can setup distcc, and have a bunch of 200mhz offline
machines get anything compiled reasonably fast. But is 800mhz really a
"plus machine" -- lets be realistic here...

> I think that a common
> situation, with different machines and machine types and production
> machines, require a big overhead either in CPU load, either to schedule,
> monitor and manage the compilations for not suffering for such CPU load
> increase.

Just get 1 offline machine to do that, and stick the packages on a
shared package repository. Whats the problem? -- it only has to be
once for a network.

> I made what you're describing, but also in my case, with the same
> machines and machine types and the CPU load increase was not a concern.
> I think that in most cases, with a smart monitoring, scheduling and
> managing and with ccache and distcc you can get the target also in more
> common situations without performance degradation in the business
> services offered by the machines, but there are concerns either for
> security (gcc installed everywhere to have distcc working) and the work
> for managing monitoring, scheduling and control the CPU load and network
> traffic increase.
Again, I only have gcc on 1 machine, and no matter how slow that
machine is, it gets thing compiled anyway. With ccache, updates take
conciderably less time and 90% of the stuff I compile on it, gets
compiled in less than an hour.

Whatever takes longer than an hour isnt a problem either since its
compiled once and distributed as a binary package to all machines.

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[andrea ferraris]

Roman Gaufman wrote:

>>You're a very patient person, or your offline machine is at least
>>a 4 3Ghz Xeon with 4 GB RAM, or you never compiled something like
>>X and/or OpenOffice  and some other nice little things ;-) .
> 
> 
> 800mhz with 256Mb ram -- why do I need a 100% up to date system? -- so
> X takes about 4 hours to compile, so what? -- what difference does it
> make?

I think almost no one and also for OpenOffice if the box hasn't better
things to do. I thought that the times were worse than which ones you 
reported for such machine.

>>It is that what you're describing is a lucky, but I fear uncommon,
>>situation: you can afford a plus machine and you don't have different
>>machines and machines types to compile for.
> 
> 
> First of all, you can setup distcc, and have a bunch of 200mhz offline
> machines get anything compiled reasonably fast. But is 800mhz really a
> "plus machine" -- lets be realistic here...

Yes, a 800 Mhz with 256 MB is not a "plus machine"

>>I think that a common
>>situation, with different machines and machine types and production
>>machines, require a big overhead either in CPU load, either to schedule,
>>monitor and manage the compilations for not suffering for such CPU load
>>increase.
> 
> 
> Just get 1 offline machine to do that, and stick the packages on a
> shared package repository. Whats the problem? -- it only has to be
> once for a network.

If you have 2-3 architectures (x86, PPC ..., 32 and 64 bits) and/or 2-3 
machine types (AMD, Intel, PIII, Celeron, Xeon) to get one binary 
packages for all the machines you have to compile the same thing many 
times, one for each architecture and machine type and then you have more 
trouble to manage the binaries and their installations (it is, b.e. you 
have to share them in different path and to install from different path 
from each different machine).

> Again, I only have gcc on 1 machine, and no matter how slow that
> machine is, it gets thing compiled anyway. With ccache, updates take
> conciderably less time and 90% of the stuff I compile on it, gets
> compiled in less than an hour.
> 
> Whatever takes longer than an hour isnt a problem either since its
> compiled once and distributed as a binary package to all machines.

I can't disagree too hardly, because I made the same thing ;-)

Andrea

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Nathaniel McCallum]

On Thu, 2004-10-21 at 11:52 +0200, Sven Vermeulen wrote:
> > The thing is that portage's binary packages are far from perfect when 
> > compared for example with rpm's. The problem is caused by the fact that 
> > two seemingly similar binary packages can be different to the extend that 
> > one will work on your system and the other not. As gentoo is mainly a 
> > source distribution the effort required to make binaries "better" is 
> > probably too big. Even then all kinds of binary problems are unavoidable 
> > and the main cause of releases in all binary distributions, even debian. 
> > With source one can mix and match, with binary releases one must ensure 
> > that all dependencies are completely compatible with the versions that 
> > existed when the package was built.
> 
> Some issues with binary releases are covered by a document that rac has on
> his dev page. It's not the official Gentoo policy, but it does make you
> think about it :)
> 
> http://dev.gentoo.org/~rac/binaries.html

These problems (as rac mentions) can somewhat be overcome by freezing
the toolchain or (as rac doesn't really mention) freezing the whole
tree.  I know freezing the tree has been mentioned as an "enterprise"
type option (having a supported tree with backported security fixes),
though it would help with desktop binary compatibility as well.

Freezing the whole tree or at least the whole tool chain would provide
us a way to not have to deal with funky compile problems as well.  For
instance, a person could always leave the frozen tree, but it wouldn't
be supported.  We would thus only support the frozen tree.  You could
also make the binary package only available within the frozen tree. So
the user could do something like this: emerge --binary-only gnome, but
this would fail: RELEASE="unstable" emerge --binary-only gnome.  I think
that gets us over most of rac's objections, no?

Nathaniel


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Luke-Jr]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Thursday 21 October 2004 7:00 pm, Nathaniel McCallum wrote:
> These problems (as rac mentions) can somewhat be overcome by freezing
> the toolchain or (as rac doesn't really mention) freezing the whole
> tree.  I know freezing the tree has been mentioned as an "enterprise"
> type option (having a supported tree with backported security fixes),
> though it would help with desktop binary compatibility as well.

Or simply by updating the RDEPEND in the binary pkg to lock it to specific 
versions of packages. The problem then would be figuring out which packages 
are binary compatible and *not* locking those.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

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

Re: [gentoo-portage-dev] Conary

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

On Thursday 21 October 2004 21:19, Luke-Jr wrote:
> On Thursday 21 October 2004 7:00 pm, Nathaniel McCallum wrote:
> > These problems (as rac mentions) can somewhat be overcome by freezing
> > the toolchain or (as rac doesn't really mention) freezing the whole
> > tree.  I know freezing the tree has been mentioned as an "enterprise"
> > type option (having a supported tree with backported security fixes),
> > though it would help with desktop binary compatibility as well.
>
> Or simply by updating the RDEPEND in the binary pkg to lock it to
> specific versions of packages. The problem then would be figuring out
> which packages are binary compatible and *not* locking those.

Unfortunately the requirements for RDEPEND in a binary package are more in 
the like of depend on library L with useflags A, B and C, and linked 
against the libraries with sonames X, Y and Z. And even for those sonames 
you would want a minimal version. In short dll hell revisited.

Paul

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

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

Re: [gentoo-portage-dev] Conary

[Jason Stubbs]

On Friday 22 October 2004 17:07, Paul de Vrieze wrote:
> On Thursday 21 October 2004 21:19, Luke-Jr wrote:
> > On Thursday 21 October 2004 7:00 pm, Nathaniel McCallum wrote:
> > > These problems (as rac mentions) can somewhat be overcome by freezing
> > > the toolchain or (as rac doesn't really mention) freezing the whole
> > > tree.  I know freezing the tree has been mentioned as an "enterprise"
> > > type option (having a supported tree with backported security fixes),
> > > though it would help with desktop binary compatibility as well.
> >
> > Or simply by updating the RDEPEND in the binary pkg to lock it to
> > specific versions of packages. The problem then would be figuring out
> > which packages are binary compatible and *not* locking those.
>
> Unfortunately the requirements for RDEPEND in a binary package are more in
> the like of depend on library L with useflags A, B and C, and linked
> against the libraries with sonames X, Y and Z. And even for those sonames
> you would want a minimal version. In short dll hell revisited.

Portage really needs to know this anyway to be able to sort out possible 
breakage when things are upgraded. Sure, everything can be scanned but that 
is very time-consuming and thus a PITA for the end-user.

Remember that the packages, once installed, are always binary and any change 
to versions are just as likely to cause breakage within the installed system 
regardless of how the new packages are installed.

Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[John Nilsson]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

> Portage really needs to know this anyway to be able to sort out possible 
> breakage when things are upgraded. Sure, everything can be scanned but that 
> is very time-consuming and thus a PITA for the end-user.
> 
> Remember that the packages, once installed, are always binary and any change 
> to versions are just as likely to cause breakage within the installed system 
> regardless of how the new packages are installed.
> 
> Regards,
> Jason Stubbs

This just as good a time as any time to bring this up:

The portage tree is getting larger and there is already talk about
making portage support download on demand... or something like that.

Why not express the dependency as an RDF graph? A dependency statement
would be a complete uri. This would also remove the need to maintain a
single package namespace.

-John

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Conary

[Jason Stubbs]

On Friday 22 October 2004 22:11, John Nilsson wrote:
> > Portage really needs to know this anyway to be able to sort out possible
> > breakage when things are upgraded. Sure, everything can be scanned but
> > that is very time-consuming and thus a PITA for the end-user.
> >
> > Remember that the packages, once installed, are always binary and any
> > change to versions are just as likely to cause breakage within the
> > installed system regardless of how the new packages are installed.
>
> This just as good a time as any time to bring this up:
>
> The portage tree is getting larger and there is already talk about
> making portage support download on demand... or something like that.
>
> Why not express the dependency as an RDF graph? A dependency statement
> would be a complete uri. This would also remove the need to maintain a
> single package namespace.

I have no idea what you are talking about, but there are no problems with 
expressing the dependencies. The "problem" is figuring out the loosest set of 
specifations that still wont break anything.

Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Friday 22 October 2004 15:11, John Nilsson wrote:
> Why not express the dependency as an RDF graph? A dependency statement
> would be a complete uri. This would also remove the need to maintain a
> single package namespace.

The problem is absolutely not with the namespace. There are 2 ways of 
namespaces, one is where every party uses it's own namespace, so 
excluding overlaps, but also taking away the advantages of other people's 
work. AND this will highly likely lead to overlapping files as there is 
overlap in the upstream packages.

The other way is where the namespaces are looser. In this case one package 
has one namespace. This however does not work either, because it moves 
the problem to inside the package, where your package A does not work 
with my dependant package C, because your package A is different than my 
package B, while A and B are supposed to be the same package.

In short, the only way to guarantee that this doesn't happen is to have a 
central tree that has a minimum quality level.

Paul

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

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

Re: [gentoo-portage-dev] Conary

[John Nilsson]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

> In short, the only way to guarantee that this doesn't happen is to have a 
> central tree that has a minimum quality level.
> 
> Paul
> 

Ofcourse every Gentoo package would depend on
<http://packages.gentoo.org/...> packages. Howerver I thought this
thread was about "loose collaboration across the Internet" between
"distributed and loosely connected
repositories".

Lets say I define <http://www.example.com/virtual/x11> to be a list of
packages that I think is compatible with X11 dependent pacakges.
If a maintainer wants to use my list as a dependency he is also
responsible for any bugs resulting from that statement. He could also
state, say <http://packages.gentoo.org/x11-base/xorg-x11?ipv6#6.8.1> if
that is the onlything that works.

Thus I could "emerge http://www.example.com/pkgs/mod_php?
mysql&mysqli#5.0" and no PRTAGE_OVERLAY would be needed, and it could
even depend on http://www.mysql.com/unstable/mysql and no gentoo
specificas has yet been involved...

-John



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Conary

[Ed Grimm]

On Thu, 21 Oct 2004, Paul de Vrieze wrote:
> On Thursday 21 October 2004 00:02, andrea ferraris wrote:
>> The first one is simple: in a litle gentoo system that I'm
>> managing for a year now with authomatic nightly updates,
>> I had to update almost manually about a hundred of
>> configuration files. The system (gentoo) is well designed,
>> so, if I didn't update, all works because the original
>> configuration files stay in place, but for the better and
>> also only for the good, the thing to do is to use etc-update
>> to update such configuration files. The problem is that such
>> process is really time consuming and error prone, so it's
>> not very good.
>
> You might want to try dispatch-conf. It is superior to etc-update in
> many aspects, and it comes with gentoolkit. Further there is normally
> no need to update every night. While there is no problem with it, it
> will increase the maintenance load unnecessarilly.

Reading the dispatch-conf(1") manpage (1<b>"</b>?), I see that it does a
certain amount of reduction of makework.  However, it does nothing to
fix my primary annoyance with Gentoo's attempts to update my /etc files.

My issue is: Gentoo's patch system does not take current state into
account in any appropriate manner.  This means that any file in /etc
which I have made changes will be updated improperly; I'll therefore
need to either throw out new changes or adapt them to my changes every
time Gentoo considers updating them.

As an example, I'm not using the standard Gentoo partition layout.  This
means that, every so often, Gentoo tries to "fix" my fstab.  It
generally does this by inserting the new values it wants to have for
each partition into the file, producing an fstab file which has multiple
mount points with the same names, but different devices and file system
formats.  I seem to recall one of the earlier attempts entirely
eliminated my config.  I'd have changed distributions over this if these
files were installed immediately.

Other files which tend to be incredibly frustrating are basic config
files.  For example, /etc/etc-update.conf.  Every time an upgrade
decides it wants to check on the status of this file, it decides that,
on the whole, I was mistaken regarding my choice of difference viewer,
and the various other options I specified.

I've generally stayed fairly silent on this matter, because it appeared
that people were aware of the problem, and I have a difficult time not
frothing over it.  However, it's apparent that the understanding that
the developers have does not come anywhere close to understanding my
problem with the current system.


Excluding program directories (for example, /etc/init.d), all changes to
existing /etc files should compensate for changes that the local
administrator has made.  For example, when upgrading a configuration
file, the new version should, as much as possible, retain the changes
that the local administrator has made.  When the ext3 filesystem tools
add a new option, any attempts to update /etc/fstab should ignore any
partitions that aren't ext3.  It should not add any partitions that it
feels are missing, either due to having ignored a reiserfs partition or
due to that partition not being there.  It should not alter any swap
partitions that haven't been modified according to a change the ext3
maintainer previously saw - it's possible it may have not been installed
here, it's possible the administrator backed it out.  It should NEVER
try to change the partition type (for example, from ext3 to xfs, like it
currently wants to do.)

If people are interested, I could potentially write a tutorial on
methods one could utilize to perform such functions.  Note that this
would be written to writing the code in perl, as I don't know python
well, and it doesn't feel natural to me.

Ed

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On Sunday 24 October 2004 05:18, Ed Grimm wrote:
> Excluding program directories (for example, /etc/init.d), all changes to
> existing /etc files should compensate for changes that the local
> administrator has made.  For example, when upgrading a configuration
> file, the new version should, as much as possible, retain the changes
> that the local administrator has made.  When the ext3 filesystem tools
> add a new option, any attempts to update /etc/fstab should ignore any
> partitions that aren't ext3.  It should not add any partitions that it
> feels are missing, either due to having ignored a reiserfs partition or
> due to that partition not being there.  It should not alter any swap
> partitions that haven't been modified according to a change the ext3
> maintainer previously saw - it's possible it may have not been installed
> here, it's possible the administrator backed it out.  It should NEVER
> try to change the partition type (for example, from ext3 to xfs, like it
> currently wants to do.)

This is what dispatch-conf will do if you give it time to work. For 
dispatch-conf to work you need to initialise it first. It works with 
three-way diffs, so without a reference (which gets created the first time a 
config file is updated with dispatch-conf) it doesn't work. For the rest, I 
suggest you write up a patch to dispatch-conf to allow it to ignore certain 
files. However it normally works quite well with fstab as the default one 
hardly changes, and you'd want to know about those changes anyway.

> If people are interested, I could potentially write a tutorial on
> methods one could utilize to perform such functions.  Note that this
> would be written to writing the code in perl, as I don't know python
> well, and it doesn't feel natural to me.

Well, go ahead

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

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

Re: [gentoo-portage-dev] Conary

[andrea ferraris]

Paul de Vrieze wrote:
> On Sunday 24 October 2004 05:18, Ed Grimm wrote:
> 
>>Excluding program directories (for example, /etc/init.d), all changes to
>>existing /etc files should compensate for changes that the local
>>administrator has made.  For example, when upgrading a configuration
>>file, the new version should, as much as possible, retain the changes
>>that the local administrator has made.  When the ext3 filesystem tools
>>add a new option, any attempts to update /etc/fstab should ignore any
>>partitions that aren't ext3.  It should not add any partitions that it
>>feels are missing, either due to having ignored a reiserfs partition or
>>due to that partition not being there.  It should not alter any swap
>>partitions that haven't been modified according to a change the ext3
>>maintainer previously saw - it's possible it may have not been installed
>>here, it's possible the administrator backed it out.  It should NEVER
>>try to change the partition type (for example, from ext3 to xfs, like it
>>currently wants to do.)
> 
> 
> This is what dispatch-conf will do if you give it time to work. For 
> dispatch-conf to work you need to initialise it first. It works with 
> three-way diffs, so without a reference (which gets created the first time a 
> config file is updated with dispatch-conf) it doesn't work. For the rest, I 
> suggest you write up a patch to dispatch-conf to allow it to ignore certain 
> files. However it normally works quite well with fstab as the default one 
> hardly changes, and you'd want to know about those changes anyway.

Thx to you and other kind replying people >

I don't made yet my homeworks (studying dispatch-conf), so I was 
replying to Ed (with congrats), saying that was needed a 3 time diff.
I think that could be more convenient the dispatch-conf way, but 
conceptually the creation of a reference is not mandatory. It's enough a 
diff between the actually installed and modified file and the original 
one of that version, since the system know which is the version of the 
original one. Then it knows which are the original lines that 
disappeared or changed and at that point it could delete such lines (or 
those that substitute them) from the new standard cfg file and merge 
only the remaining diffs and in any case it shouldn't never substitute 
custom changes with standard in cfg files. Then it could not be bad one 
comment line at the beginning of new std cfg file where is written what 
changed and why (I know that for the developers could be annoying, but 
it should not take more than 1-2 minutes).

>>If people are interested, I could potentially write a tutorial on
>>methods one could utilize to perform such functions.  Note that this
>>would be written to writing the code in perl, as I don't know python
>>well, and it doesn't feel natural to me.
 >
 >
 > Well, go ahead
 >

There are no problem, I know neither python neither perl, so I'm the 
perfect candidate to translate your perl script in python ;-) because 
I'd like to learn python.
Anyway I know awk.

Andrea

P.S.: I'd like that someone for curiosity studied Conary to see what and 
how can be ported to gentoo portage, but I seen that my attempt has not 
been a very big success ;-), so maybe in my spare time, I'll try to do 
such thing myself and report here the results in the hope that you can 
teach me some about portage.

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Sunday 24 October 2004 13:27, andrea ferraris wrote:
> conceptually the creation of a reference is not mandatory. It's enough a
> diff between the actually installed and modified file and the original
> one of that version, since the system know which is the version of the
> original one. Then it knows which are the original lines that

Unfortunately the original version is normally not backed up so lost. Only the 
md5sum of the original version is recorded. md5sums can not (should not be 
able to) be used to to reconstruct the original. Dispatch conf does create 
such a backup and allow this three-way conf.

Paul

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

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

Re: [gentoo-portage-dev] Conary

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On Sat, Oct 23, 2004 at 10:18:56PM -0500, Ed Grimm wrote:
> My issue is: Gentoo's patch system does not take current state into
> account in any appropriate manner.  This means that any file in /etc
> which I have made changes will be updated improperly; I'll therefore
> need to either throw out new changes or adapt them to my changes every
> time Gentoo considers updating them.

I don't think it's possible to magically update configuration files that you
have altered and be able to tell you that the updated configuration file
still is 100% functional.

It is possible if we only support a subset of configuration parameters,
store them elsewhere and merge those with a script in the updated
configuration file. Some distributions use this method, and it is a major
annoyance.

> As an example, I'm not using the standard Gentoo partition layout.  This
> means that, every so often, Gentoo tries to "fix" my fstab. 

Ignore the update. There is no reason why you should update your /etc/fstab;
unless you alter filesystems or partition layouts, /etc/fstab is static.

> Other files which tend to be incredibly frustrating are basic config
> files.  For example, /etc/etc-update.conf.  Every time an upgrade
> decides it wants to check on the status of this file, it decides that,
> on the whole, I was mistaken regarding my choice of difference viewer,
> and the various other options I specified.

You can interactively merge the changes. Most of the time, you can easily
skim through the changes it proposes and decide that there is no need to
merge them.

Wkr,
      Sven Vermeulen

-- 
  Documentation & PR project leader

  The Gentoo Project   <<< http://www.gentoo.org >>>

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

Re: [gentoo-portage-dev] Conary

[andrea ferraris]

Sven Vermeulen wrote:
> On Sat, Oct 23, 2004 at 10:18:56PM -0500, Ed Grimm wrote:
> 
>>My issue is: Gentoo's patch system does not take current state into
>>account in any appropriate manner.  This means that any file in /etc
>>which I have made changes will be updated improperly; I'll therefore
>>need to either throw out new changes or adapt them to my changes every
>>time Gentoo considers updating them.
> 
> 
> I don't think it's possible to magically update configuration files that you
> have altered and be able to tell you that the updated configuration file
> still is 100% functional.

100% maybe not, but actually the gentoo way is 0% and maybe between 0 
and 100 there are some other figures ;-)

>>As an example, I'm not using the standard Gentoo partition layout.  This
>>means that, every so often, Gentoo tries to "fix" my fstab. 
> 
> 
> Ignore the update. There is no reason why you should update your /etc/fstab;
> unless you alter filesystems or partition layouts, /etc/fstab is static.

I did that most times, but why I have to do it?!
To avoid such annoyance it's not needed AI or grid computing, it's 
enough Animal Intelligence ;-) anyway Scriptable Intelligence.

>>Other files which tend to be incredibly frustrating are basic config
>>files.  For example, /etc/etc-update.conf.  Every time an upgrade
>>decides it wants to check on the status of this file, it decides that,
>>on the whole, I was mistaken regarding my choice of difference viewer,
>>and the various other options I specified.
> 
> 
> You can interactively merge the changes. Most of the time, you can easily
> skim through the changes it proposes and decide that there is no need to
> merge them.

As said, but why I have to do that if most times it could be avoided by 
means of a kind script?

Andrea

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary - dispatch-conf

[LinuxGuy]

Hi there, i've been putting in alot of work on dispatch-conf lately,
adding features i personally need, and features that it should have. I
have a new version of dispatch-conf posted at bug:
http://bugs.gentoo.org/show_bug.cgi?id=68618

i believe it will solve one of your major problems with dispatch-conf as
i have added a new option called "config file freezing" which allows you
to specify config files you never want to be overwritten, like
/etc/fstab /etc/password and /etc/group and so on. instead it will take
the new files that portage tries to pass out and apply them to rcs (or
archive them through whatever meathod you are using). I'm also taking
suggestions on features to be added, so if you, or anyone else feels
there are other features that should be added email me about it and
we'll talk about what/how should be added.


On 22:18 Sat 23 Oct     , Ed Grimm wrote:
> On Thu, 21 Oct 2004, Paul de Vrieze wrote:
> > On Thursday 21 October 2004 00:02, andrea ferraris wrote:
> >> The first one is simple: in a litle gentoo system that I'm
> >> managing for a year now with authomatic nightly updates,
> >> I had to update almost manually about a hundred of
> >> configuration files. The system (gentoo) is well designed,
> >> so, if I didn't update, all works because the original
> >> configuration files stay in place, but for the better and
> >> also only for the good, the thing to do is to use etc-update
> >> to update such configuration files. The problem is that such
> >> process is really time consuming and error prone, so it's
> >> not very good.
> >
> > You might want to try dispatch-conf. It is superior to etc-update in
> > many aspects, and it comes with gentoolkit. Further there is normally
> > no need to update every night. While there is no problem with it, it
> > will increase the maintenance load unnecessarilly.
> 
> Reading the dispatch-conf(1") manpage (1<b>"</b>?), I see that it does a
> certain amount of reduction of makework.  However, it does nothing to
> fix my primary annoyance with Gentoo's attempts to update my /etc files.
> 
> My issue is: Gentoo's patch system does not take current state into
> account in any appropriate manner.  This means that any file in /etc
> which I have made changes will be updated improperly; I'll therefore
> need to either throw out new changes or adapt them to my changes every
> time Gentoo considers updating them.
> 
> As an example, I'm not using the standard Gentoo partition layout.  This
> means that, every so often, Gentoo tries to "fix" my fstab.  It
> generally does this by inserting the new values it wants to have for
> each partition into the file, producing an fstab file which has multiple
> mount points with the same names, but different devices and file system
> formats.  I seem to recall one of the earlier attempts entirely
> eliminated my config.  I'd have changed distributions over this if these
> files were installed immediately.
> 
> Other files which tend to be incredibly frustrating are basic config
> files.  For example, /etc/etc-update.conf.  Every time an upgrade
> decides it wants to check on the status of this file, it decides that,
> on the whole, I was mistaken regarding my choice of difference viewer,
> and the various other options I specified.
> 
> I've generally stayed fairly silent on this matter, because it appeared
> that people were aware of the problem, and I have a difficult time not
> frothing over it.  However, it's apparent that the understanding that
> the developers have does not come anywhere close to understanding my
> problem with the current system.
> 
> 
> Excluding program directories (for example, /etc/init.d), all changes to
> existing /etc files should compensate for changes that the local
> administrator has made.  For example, when upgrading a configuration
> file, the new version should, as much as possible, retain the changes
> that the local administrator has made.  When the ext3 filesystem tools
> add a new option, any attempts to update /etc/fstab should ignore any
> partitions that aren't ext3.  It should not add any partitions that it
> feels are missing, either due to having ignored a reiserfs partition or
> due to that partition not being there.  It should not alter any swap
> partitions that haven't been modified according to a change the ext3
> maintainer previously saw - it's possible it may have not been installed
> here, it's possible the administrator backed it out.  It should NEVER
> try to change the partition type (for example, from ext3 to xfs, like it
> currently wants to do.)
> 
> If people are interested, I could potentially write a tutorial on
> methods one could utilize to perform such functions.  Note that this
> would be written to writing the code in perl, as I don't know python
> well, and it doesn't feel natural to me.
> 
> Ed
> 
> --
> gentoo-portage-dev@gentoo.org mailing list
> 


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary - dispatch-conf

[Ed Grimm]

On Mon, 25 Oct 2004 LinuxGuy@Cox.net wrote:

> Hi there, i've been putting in alot of work on dispatch-conf lately,
> adding features i personally need, and features that it should have. I
> have a new version of dispatch-conf posted at bug:
> http://bugs.gentoo.org/show_bug.cgi?id=68618
>
> i believe it will solve one of your major problems with dispatch-conf as
> i have added a new option called "config file freezing" which allows you
> to specify config files you never want to be overwritten, like
> /etc/fstab /etc/password and /etc/group and so on. instead it will take
> the new files that portage tries to pass out and apply them to rcs (or
> archive them through whatever meathod you are using). I'm also taking
> suggestions on features to be added, so if you, or anyone else feels
> there are other features that should be added email me about it and
> we'll talk about what/how should be added.

This does sound promising.  Note that I cannot fathom any reason why I'd
want Gentoo's suggested updates archived into RCS for frozen files,
unless they were not placed on the main branch - I use RCS to track my
own changes, and I don't appreciate <censored>.

Ed

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary - dispatch-conf

[LinuxGuy]

On 21:55 Wed 27 Oct     , Ed Grimm wrote:
> On Mon, 25 Oct 2004 LinuxGuy@Cox.net wrote:
> 
> > Hi there, i've been putting in alot of work on dispatch-conf lately,
> > adding features i personally need, and features that it should have. I
> > have a new version of dispatch-conf posted at bug:
> > http://bugs.gentoo.org/show_bug.cgi?id=68618
> >
> > i believe it will solve one of your major problems with dispatch-conf as
> > i have added a new option called "config file freezing" which allows you
> > to specify config files you never want to be overwritten, like
> > /etc/fstab /etc/password and /etc/group and so on. instead it will take
> > the new files that portage tries to pass out and apply them to rcs (or
> > archive them through whatever meathod you are using). I'm also taking
> > suggestions on features to be added, so if you, or anyone else feels
> > there are other features that should be added email me about it and
> > we'll talk about what/how should be added.
> 
> This does sound promising.  Note that I cannot fathom any reason why I'd
> want Gentoo's suggested updates archived into RCS for frozen files,
> unless they were not placed on the main branch - I use RCS to track my
> own changes, and I don't appreciate <censored>.
> 
> Ed
> 

A good point i suppose, my reasoning for adding the new files to rcs was
in case there were important changes in the new gentoo files that you
needed, though i suppose those files can be grabbed by recompiling,
however if it's a large app that can be a bit of a hassle. perhaps the
new configs for frozen files should be added to a different archive? or
perhaps to another file? filefoo_frozen or something? i'd like to hear
what others think about the issue.

also, several new features have been added as well, all command line
options. -c for "clobberall" which will overwrite all config files that
are not frozen without asking you anything. -p for "pretend" which will
display all files to be updated (with purdy colors {trying to mimic the
merge look}, frozen in blue, others in green). -a for "ask", like emerge
ask, and -f for "force" which will force all files to update even if
frozen.

more detailed explainations, along with the file for your testing
enjoyment are here:
http://bugs.gentoo.org/show_bug.cgi?id=68618

another feature i was thinking of adding was a simple command line based
way to add/subtract frozen files, like euse -E and -D. anything think
this is a good or bad idea?

lastly, Ed, i was a little confused by your last statment:
and I don't appreciate <censored>.
i can't think of a swear that fits here, should i be offended? or was it
just a joke? either way, i missed it. oh well.

i appreciate any feedback on this so i can continue to improve
dispatch-conf


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary - dispatch-conf

[Ed Grimm]

On Thu, 28 Oct 2004 LinuxGuy@Cox.net wrote:
> On 21:55 Wed 27 Oct     , Ed Grimm wrote:
>> On Mon, 25 Oct 2004 LinuxGuy@Cox.net wrote:
>>
>>> Hi there, i've been putting in alot of work on dispatch-conf lately,
>>> adding features i personally need, and features that it should have.
>>> I have a new version of dispatch-conf posted at bug:
>>> http://bugs.gentoo.org/show_bug.cgi?id=68618
>>>
>>> i believe it will solve one of your major problems with
>>> dispatch-conf as i have added a new option called "config file
>>> freezing" which allows you to specify config files you never want to
>>> be overwritten, like /etc/fstab /etc/password and /etc/group and so
>>> on. instead it will take the new files that portage tries to pass
>>> out and apply them to rcs (or archive them through whatever meathod
>>> you are using). I'm also taking suggestions on features to be added,
>>> so if you, or anyone else feels there are other features that should
>>> be added email me about it and we'll talk about what/how should be
>>> added.
>>
>> This does sound promising.  Note that I cannot fathom any reason why I'd
>> want Gentoo's suggested updates archived into RCS for frozen files,
>> unless they were not placed on the main branch - I use RCS to track my
>> own changes, and I don't appreciate <censored>.
>>
>> Ed
>
> A good point i suppose, my reasoning for adding the new files to rcs
> was in case there were important changes in the new gentoo files that
> you needed, though i suppose those files can be grabbed by
> recompiling, however if it's a large app that can be a bit of a
> hassle. perhaps the new configs for frozen files should be added to a
> different archive? or perhaps to another file? filefoo_frozen or
> something? i'd like to hear what others think about the issue.
>
<snip updates plug>
>
> another feature i was thinking of adding was a simple command line based
> way to add/subtract frozen files, like euse -E and -D. anything think
> this is a good or bad idea?
>
> lastly, Ed, i was a little confused by your last statment:
> and I don't appreciate <censored>.
> i can't think of a swear that fits here, should i be offended? or was
> it just a joke? either way, i missed it. oh well.
>
> i appreciate any feedback on this so i can continue to improve
> dispatch-conf

Not just one word.  I think it would've been more clear had I ended with

    and I don't appreciate <rant censored>

but I didn't think about the inclusion of that additional word.  Note
that the censored rant was actually more directed at some various
proprietary programs with which I've interacted, but the behavior you
were talking about sounded the same.

However, I've since learned that it only updates the RCS in its own RCS
store, leaving the default RCS stores alone.  So we're all happy on this
point.


That having been said... there's one lesson you should've taken from
etc-update: vimdiff support.

Specifically, there appears to be no documentation regarding the
interactive merge option, and it appears to assume a fixed screen
resolution which is not similar enough to my screen resolution, editing
the new file with $EDITOR requires that I make all of my previous edits
by hand, by memory, the first time, and under no circumstances does it
allow you to view the differences while one updates.

I suspect that one could add support for this option by testing for the
existance of the pager option, and if it is not defined, invoke the
'diff' program without piping its output anywhere.  (Note: I have gotten
some success using a pager of 'cat'.  But vimdiff is not really happy
with this option; it complains, and there's added latency, sometimes in
unpleasant parts of the update.)

Note that the behavior of dispatch-conf without one of its current
mandatory options is probably not what is intended.  I cannot be certain
of what was intended, but I'd expect it to completely abort, which is
not what it did.  I'm not fully certain of what it did, but it was
something with RCS in its own tree, which did not touch any of my files
so far as I'm able to tell.

Ed

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Conary - dispatch-conf

[LinuxGuy]

On 09:23 Fri 12 Nov     , Ed Grimm wrote:
> On Thu, 28 Oct 2004 LinuxGuy@Cox.net wrote:
> > On 21:55 Wed 27 Oct     , Ed Grimm wrote:
> >> On Mon, 25 Oct 2004 LinuxGuy@Cox.net wrote:
> >>
> >>> Hi there, i've been putting in alot of work on dispatch-conf lately,
> >>> adding features i personally need, and features that it should have.
> >>> I have a new version of dispatch-conf posted at bug:
> >>> http://bugs.gentoo.org/show_bug.cgi?id=68618
> >>>
> >>> i believe it will solve one of your major problems with
> >>> dispatch-conf as i have added a new option called "config file
> >>> freezing" which allows you to specify config files you never want to
> >>> be overwritten, like /etc/fstab /etc/password and /etc/group and so
> >>> on. instead it will take the new files that portage tries to pass
> >>> out and apply them to rcs (or archive them through whatever meathod
> >>> you are using). I'm also taking suggestions on features to be added,
> >>> so if you, or anyone else feels there are other features that should
> >>> be added email me about it and we'll talk about what/how should be
> >>> added.
> >>
> >> This does sound promising.  Note that I cannot fathom any reason why I'd
> >> want Gentoo's suggested updates archived into RCS for frozen files,
> >> unless they were not placed on the main branch - I use RCS to track my
> >> own changes, and I don't appreciate <censored>.
> >>
> >> Ed
> >
> > A good point i suppose, my reasoning for adding the new files to rcs
> > was in case there were important changes in the new gentoo files that
> > you needed, though i suppose those files can be grabbed by
> > recompiling, however if it's a large app that can be a bit of a
> > hassle. perhaps the new configs for frozen files should be added to a
> > different archive? or perhaps to another file? filefoo_frozen or
> > something? i'd like to hear what others think about the issue.
> >
> <snip updates plug>
> >
> > another feature i was thinking of adding was a simple command line based
> > way to add/subtract frozen files, like euse -E and -D. anything think
> > this is a good or bad idea?
> >
> > lastly, Ed, i was a little confused by your last statment:
> > and I don't appreciate <censored>.
> > i can't think of a swear that fits here, should i be offended? or was
> > it just a joke? either way, i missed it. oh well.
> >
> > i appreciate any feedback on this so i can continue to improve
> > dispatch-conf
> 
> Not just one word.  I think it would've been more clear had I ended with
> 
>     and I don't appreciate <rant censored>
> 
> but I didn't think about the inclusion of that additional word.  Note
> that the censored rant was actually more directed at some various
> proprietary programs with which I've interacted, but the behavior you
> were talking about sounded the same.
> 
> However, I've since learned that it only updates the RCS in its own RCS
> store, leaving the default RCS stores alone.  So we're all happy on this
> point.
> 
ok, cool, then i'll leave it the way it is, allowing it to add the
"gentoo recommended" configs for frozen files to the /etc/config-archive
RCS tree.
> 
> That having been said... there's one lesson you should've taken from
> etc-update: vimdiff support.
> 
two things here, first off, i think you misunderstand, i am not the
orginal coder of dispatch-conf, from what i gather he dissapeared at
some point. i just picked up dispatch-conf and started adding features
that i needed/wanted.

also, vimdiff sounds like a great idea! (i didn't even know such a thing
existed) but what about our emacs friends? is there an emacsdiff or
similar? i'd hate to trap a poor emacs user in a vi session :)

> Specifically, there appears to be no documentation regarding the
> interactive merge option, and it appears to assume a fixed screen
> resolution which is not similar enough to my screen resolution, editing
> the new file with $EDITOR requires that I make all of my previous edits
> by hand, by memory, the first time, and under no circumstances does it
> allow you to view the differences while one updates.
> 
> I suspect that one could add support for this option by testing for the
> existance of the pager option, and if it is not defined, invoke the
> 'diff' program without piping its output anywhere.  (Note: I have gotten
> some success using a pager of 'cat'.  But vimdiff is not really happy
> with this option; it complains, and there's added latency, sometimes in
> unpleasant parts of the update.)
> 
> Note that the behavior of dispatch-conf without one of its current
> mandatory options is probably not what is intended.  I cannot be certain
> of what was intended, but I'd expect it to completely abort, which is
> not what it did.  I'm not fully certain of what it did, but it was
> something with RCS in its own tree, which did not touch any of my files
> so far as I'm able to tell.

dispatch-conf doesn't have any mandatory options, when run with no
options it simply starts an interactive update of your config files. if
you have:

replace-cvs=yes
replace-wscomments=yes
replace-unmodified=yes

in your /etc/dispatch-conf.conf then it will automatically merge files
with only CVS header differences, whitespace and comments differences,
or files that the user has not modified himself (this option doesn't
seem to work 100% of the time, i havn't gone into the code to see how it
works/what's wrong with it yet)

thanks for your input Ed, once i get some more time to mess with
dispatch-conf i'll take a look at the issues you brought up.


--
gentoo-portage-dev@gentoo.org mailing list