If the description is correct then you're trying to solve the problem at
the wrong level (and it's already solved long ago, just in case).
It may well be the case for RH users but the rest of the world wasn't
staying with basic package management when the most abstract thing is a
package -- it's OK but people need more, so package repositories
and tools to handle collections of packages were (re)invented.
Re "loosely connected": you loose indeed at least on library version hell
(the price is synchronization efforts by version bloat, the more efforts
or versions, the more chance for such thing to work). Or is there some
other solution within precompiled binary package paradigm?
[»]
Re: Errr.... concept level mismatch?
by Tim P. Gerla - Sep 21st 2004 20:37:18
> Did you ever see apt or yum tools?
>
> If the description is correct then
> you're trying to solve the problem at
> the wrong level (and it's already solved
> long ago, just in case).
>
> It may well be the case for RH users but
> the rest of the world wasn't staying
> with basic package management when the
> most abstract thing is a package -- it's
> OK but people need more, so package
> repositories and tools to handle
> collections of packages were
> (re)invented.
>
> But see: it's a different layer, they
> didn't throw lower-level tools like rpm
> and dpkg out of the window since they do
> their job at their level reasonably
> well. It's just that it's not their job
> to operate at a higher level.
>
> Re "loosely connected": you loose indeed
> at least on library version hell (the
> price is synchronization efforts by
> version bloat, the more efforts or
> versions, the more chance for such thing
> to work). Or is there some other
> solution within precompiled binary
> package paradigm?
Hi,
One of the many problems Conary solves is the problem that separate
APT/Yum repositories don't always coexist nicely with each other. Hence,
you have to resort to hacks in your version strings of your packages like
epochs, ".alt1", ".alt2", "fc1", "fr", ad nauseum. Conary solves this and
many other problems, as described in the short
whitepaper.
Conary solves real-life problems that apt/yum can't properly solve because
of underlying inflexibilities with RPM and deb formats.
Please read the white papers posted at http://wiki.specifix.com/ -- they're
well-written and provide a good introduction to what Conary does, the
problems it solves, and how it has been designed from the ground up to fix
many shortcomings and weaknesses that apt and yum just can't touch.
-Tim
[reply]
[top]
[»]
Re: Errr.... concept level mismatch?
by Michael Shigorin - Sep 21st 2004 23:31:33
Uff... One of the problems Conary solves is indeed inadequate and overly
in-house RedHat's approach to package repos of the past. You talk of
"local changes" but if they're persistent, wide-scale and generally
reasonable then they belong to the upstream repository as either bugfixes
or enhancements. To achieve that, upstream ought to be listening to you
(or me, or the fellow administrator doing local changes).
*That* is a problem, but it's organizational one, not technical. And the
whitepaper's author seems to understand that as he mentions things "...not
designed to facilitate forking" but that's exactly what they get used for:
persisting difference from upstream instead of fixing that.
Please get me right, I'm not blaming you for the software, I'm (yes,)
blaming you for trying to fix a braindead thing: it's like patching
Sendmail or BIND8 instead of throwing it out of the window and getting
more straight approach implemented.
If the upstream doesn't work, fix it or change it.
[tbc]
--
Michael Shigorin
mike SOMEWHERE AT altlinux PLUS DOT org
[reply]
[top]
[»]
"Real-life problems" revisited
by Michael Shigorin - Sep 22nd 2004 00:00:41
[part2]
Continuing on "real-life problems"...
Re versions, you have to tag different builds of the same upstream source
(e.g. mozilla-1.7.3) with different patches or configure keys and maybe a
different build environment altogether. So why you call build tags
"hacks" but then reinvent the bigger and better wheel with
(auto-)assigning longer versions and then crumming them down to be "like
usually"? ;-)
Re "files being replaced", it's exactly what I've talked above --
braindead upstream packaging of a given package. Even RPM has quite
developed system for marking files as "%config(noreplace)" to simply put
the newer versions aside if the file in question *has* changed ("quite
developed" since there are another interesting possibilities, including
what's to determine its "changedness"). (and yes, if you need to patch
an initscript, that's the same diagnosis: the packager should have
provided some configurable include to modify instead of hardwiring things
into a script)
Re permissions, at least ALT Linux (you seem to have looked at that,
right? ;-) and Owl GNU/*/Linux use control(8) system to support persistent
and replicatable state of permissions (originally; in fact, much more) of
controlled files. It's a very simple and reviewable set of shell scripts
which is quite self-contained and adding the support to the package means
creating and packaging one more file and calling update scripts in
%pre/%post.
That's quite convenient for sysadmins, and some of them add control
scriptlets of their own for things they like to have controlled.
Re "changing what's really changed" -- SuSE has developed "patch RPMs"
(which were recently discussed in devel@altlinux too) to carry over only
the changes since the base version; it may be reasonable for security
updates with monsters like desktop environments or integrated applications
traffic/time-wise but doesn't help much in development environment.
Re kernel modules -- what if the kernel packaging system allows for
building and packaging modules independently
as well as maintaining the kernel patches in a definite form so that it's
possible to improve the "fix"/"feat" package and have a kernel rebuild
with no effort? (heck, I'm known in local communities for teaching
people *not* to waste time on building kernels but to choose the proper
distros where Things Just Work ;-)
All in all: choose proper distro, be it Debian, SuSE, Fedora (?), ALT or
whatever team listens to you and fixes the bugs and allows you to add
features that may be beneficial to the wider community. It's more
productive than "fixin' a hole where the rain gets in, \ stops my mind
from wonderin'..." :-)
[tbc]
--
Michael Shigorin
mike SOMEWHERE AT altlinux PLUS DOT org
[reply]
[top]
[»]
Re: Errr.... concept level mismatch?
by Michael Shigorin - Sep 22nd 2004 00:05:47
Roundup: if Conary solves the problems something has introduced to you,
that's fine. I'd just to remind you that doing things which will
virtually never be accepted upstream is a significant waste of time, and
for software management system it means at least "widely accepted in
appropriate software community".
But if there's a community to talk about, it should be better off
fixing real problems not building the workaround scaffolding, as discussed
in previous snippet.
Regards anyway.
--
Michael Shigorin
mike SOMEWHERE AT altlinux PLUS DOT org
[reply]
[top]
[»]
Re: Errr.... concept level mismatch?
by Giles - Apr 7th 2005 09:47:27
> Did you ever see apt or yum tools?
>
> If the description is correct then
> you're trying to solve the problem at
> the wrong level (and it's already solved
> long ago, just in case).
>
> It may well be the case for RH users but
> the rest of the world wasn't staying
> with basic package management when the
> most abstract thing is a package -- it's
> OK but people need more, so package
> repositories and tools to handle
> collections of packages were
> (re)invented.
>
> But see: it's a different layer, they
> didn't throw lower-level tools like rpm
> and dpkg out of the window since they do
> their job at their level reasonably
> well. It's just that it's not their job
> to operate at a higher level.
>
> Re "loosely connected": you loose indeed
> at least on library version hell (the
> price is synchronization efforts by
> version bloat, the more efforts or
> versions, the more chance for such thing
> to work). Or is there some other
> solution within precompiled binary
> package paradigm?
Okay here's a thought - you obviously don't "get it", and this leads me to
believe that you clearly have yet to experience Conary, so why not downoad
a distro that uses it, such as Specifix or Foresight, and actually have a
good look at it before giving us all the pleasure of your ill-informed
review?
[reply]
[top]
[»]
Re: Errr.... concept level mismatch?
by Michael Shigorin - Apr 7th 2005 10:48:54
> Okay here's a thought - you obviously
> don't "get it", and this leads me to
> believe that you clearly have yet to
> experience Conary
Yep, I don't "get it". Mind you, I'm both systems administrator,
maintainer of some 100+ packages, and doing/using quite some mirrors, 3rd
party repositories and so on. Somewhat working on distros and branches
management also. Still don't.
> so why not downoad a
> distro that uses it, such as Specifix or
> Foresight, and actually have a good look
> at it before giving us all the pleasure
> of your ill-informed review?
Hm, and why download distro which seems to be announced as "still
immature" proof-of-concept if *two* quite different build systems on top
of apt-rpm I'm using right now to *exactly* build distributions -- both
tweaking desktop one and creating server appliance one -- and things Just
Work, with these technologies being mature and established? Just for
respect for Erik Troan? No thanks, I owe Red Hat quite a few users with
"full install" illness.
RPM and dpkg don't contraverse "loose collaboration" to me, so there's no
sense to junk them (instead of building on top). Production doesn't mean
Gentoo and similar approaches to me too just because it's *too*
loose.
Yes, I've initially missed the "embedded" word in positioning of Specifix;
but hey it's not anywhere in Conary's CV, maybe the description should be
updated.
And yes, I've read several documents on project's site before getting my
ill-informed comments here. Just because there's no good reason to
reinvent the very basic wheel when there's more reason to focus on
higher-level issues of package [cluster] management, I'd better spend that
time looking on Smart. Maybe one day our
building systems will get ported to that.
PS: please don't take it too personally, just so tired with splintering
and reinventing that happens all the time anyways... Good luck if it
works for you, I'll just have to cope with my ill-born toys sitting two
conceptual levels higher. :-)
--
Michael Shigorin
mike SOMEWHERE AT altlinux PLUS DOT org
[reply]
[top]
I really think the conary folks have the right idea. The concept of
maintaining packages like a source tree is just what we need. This is the
provisioning system that is necessary to make Linux win in a large
corporate environment.
