distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

Having 3+ packages within a single "main" repository is
pretty bulky. Would it be possible to distinguish between
the "core" Debian and "main" somehow?

I don't want to keep anybody out. I just would like to use
the core packages of Debian release xyz (all the essential
packages, for example) together with more up-to-date
packages in testing (kernel & drivers, development tools,
eye candy, games, etc).

I checked Google for this, but I didn't find it mentioned
before.


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3pxoAACgkQUTlbRTxpHjfBMgCfecRKDdPb3QZZriyZiMEY8IYx
3QEAn2AOCNFqAudYrBxNeFzQJ5gIvIe4
=GseN
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de9c680.70...@afaics.de

Re: distinguish between "core" and "main"?

[Paul Wise]

Sounds like you are looking for backports.debian.org?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTinAFUyM1LUDT=szcawxsxx403g...@mail.gmail.com

Re: distinguish between "core" and "main"?

[Thijs Kinkhorst]

On Sat, June 4, 2011 07:45, Harald Dunkel wrote:
> Having 3+ packages within a single "main" repository is
> pretty bulky. Would it be possible to distinguish between
> the "core" Debian and "main" somehow?
>
> I don't want to keep anybody out. I just would like to use
> the core packages of Debian release xyz (all the essential
> packages, for example) together with more up-to-date
> packages in testing (kernel & drivers, development tools,
> eye candy, games, etc).

I think package priorities may help you. Debian Policy describes what
types of packages to expect in each of these, and you may decide that for
your purposes you take required, required+important or
required+important+standard to be "core Debian":
http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities


Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e2d706e63e854b3c34f2d5badfc024d4.squir...@wm.kinkhorst.nl

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/04/11 07:56, Paul Wise wrote:
> Sounds like you are looking for backports.debian.org?
> 

Backports for Squeeze contains just about 400 package,
AFIACS.


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3p1pIACgkQUTlbRTxpHje1AwCdE1Wv9qw7wawoyZaUErkPrITg
wAMAoIaw5gbjlYsdUvFmrTkInqkwsTqs
=lS8N
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de9d692.3000...@afaics.de

Re: distinguish between "core" and "main"?

[Paul Wise]

On Sat, Jun 4, 2011 at 2:54 PM, Harald Dunkel  wrote:

> Backports for Squeeze contains just about 400 package,
> AFIACS.

Yep, if you want more you should either build (and upload) them
yourself or talk to the maintainers of the ones you want and get them
to build and upload them.

Alternatively you might want to install from testing directly. Not
everything from testing is installable on stable, which is where
backports comes in.

If you install from testing directly you will need some apt pinning:

http://wiki.debian.org/AptPreferences

Set your /etc/apt/preferences to the below and cherry-pick packages
from testing (or squeeze-backports/unstable/experimental). You will
probably encounter dependency issues, conflicts and compatibility
bugs, but apt-get upgrade will where installed, upgrade packages
within testing. Switch to a backport to avoid those issues.

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=squeeze-backports
Pin-Priority: 850

Package: *
Pin: release a=testing
Pin-Priority: 800

Package: *
Pin: release a=unstable
Pin-Priority: 700

Package: *
Pin: release a=experimental
Pin-Priority: 600

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTiniAgW+sKsjv-GaP=ksxhutlii...@mail.gmail.com

Re: distinguish between "core" and "main"?

[Russ Allbery]

Harald Dunkel  writes:

> I don't want to keep anybody out. I just would like to use the core
> packages of Debian release xyz (all the essential packages, for example)
> together with more up-to-date packages in testing (kernel & drivers,
> development tools, eye candy, games, etc).

Well, I'm afraid the short version is "you can't."  All those up-to-date
packages depend on newer versions of the core packages than released with
stable, particularly newer versions of the libraries, other than those
that have been backported.  So by the time you install the up-to-date
packages in testing, you will have upgraded most of your core system
(particularly the bits that are most likely to have problems) to testing
anyway.

In other words, why not just use testing?  You're not gaining anything
from trying to keep only essential packages at stable.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hb86ulc6@windlord.stanford.edu

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/04/11 09:05, Paul Wise wrote:
> Alternatively you might want to install from testing directly. Not
> everything from testing is installable on stable, which is where
> backports comes in.

Installing testing for the whole system is no option. The base
system (the core packages) should be provided by the most recent
release. I don't want to get an unbootable system.

> 
> If you install from testing directly you will need some apt pinning:
> 
> http://wiki.debian.org/AptPreferences
> 
> Set your /etc/apt/preferences to the below and cherry-pick packages
> from testing (or squeeze-backports/unstable/experimental). You will
> probably encounter dependency issues, conflicts and compatibility
> bugs, but apt-get upgrade will where installed, upgrade packages
> within testing. Switch to a backport to avoid those issues.
> 

This sounds like a lot of manual work. I can do that for my own desktop
PC, but not for all the desktops and servers in the office.

I would prefer if Debian distinguishes between core and main instead.
This means splitting the current main repository.

In the new system the main/testing packages should be _guaranteed_
to work together with the most recent core/stable packages. Of course
they should also work together with core/testing, as they do now.

Making this scheme work would imply more frequent releases for the core
packages, but I am sure this can be done. I would expect that we would
get <1000 core packages.

Hopefully its OK if I post my ideas here? Actually this is about release
management, not about development.


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3p6PYACgkQUTlbRTxpHjdidwCfYWqYYAQIL8oiGrxb+psVX8nf
2PwAnR15E6Juy3N0p/mtbYV8y34CLw98
=Kalf
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de9e8fa.3060...@afaics.de

Re: distinguish between "core" and "main"?

[Andrei POPESCU]

On Sb, 04 iun 11, 10:12:42, Harald Dunkel wrote:
> 
> I would prefer if Debian distinguishes between core and main instead.
> This means splitting the current main repository.
> 
> In the new system the main/testing packages should be _guaranteed_
> to work together with the most recent core/stable packages. Of course
> they should also work together with core/testing, as they do now.
> 
> Making this scheme work would imply more frequent releases for the core
> packages, but I am sure this can be done. I would expect that we would
> get <1000 core packages.
> 
> Hopefully its OK if I post my ideas here? Actually this is about release
> management, not about development.

This is one of those recurrent discussions coming up on debian-devel. It 
is my impression (as a lurker) that most Debian Developers do not want 
to have second-class packages and it is a feature that all packages in 
main get (more or less) the same treatment regarding release and 
security support.

Maybe Ubuntu is a better fit for your needs?

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: distinguish between "core" and "main"?

[Neil Williams]

On Sat, 04 Jun 2011 07:45:36 +0200
Harald Dunkel  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi folks,
> 
> Having 3+ packages within a single "main" repository is
> pretty bulky. Would it be possible to distinguish between
> the "core" Debian and "main" somehow?

The principle division mechanism is Priority: because there are Policy
requirements that Priority: divisions (with the exception of the less
than useful optional|extra division) take account of the dependencies
of the packages included.

Emdebian does use Section: to sub-divide what would otherwise all be
optional|extra but it requires quite a few altered overrides to keep the 
dependencies in line. That is done to cut down the size of the Packages file in 
main for embedded systems.

> I don't want to keep anybody out. I just would like to use
> the core packages of Debian release xyz (all the essential
> packages, for example) together with more up-to-date
> packages in testing (kernel & drivers, development tools,
> eye candy, games, etc).

Mixed systems are always awkward because that one system could well be
the only system with that precise mix of versions.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpaqDekL1CB7.pgp
Description: PGP signature

Re: distinguish between "core" and "main"?

[Neil Williams]

On Sat, 04 Jun 2011 10:12:42 +0200
Harald Dunkel  wrote:

> Installing testing for the whole system is no option. The base
> system (the core packages) should be provided by the most recent
> release. I don't want to get an unbootable system.

You are more likely to get a problematic system by MIXING versions than
you are by sticking just to stable or just to testing. Unbootable is
fairly unlikely (boot loader bugs aside).

The fewer people are running that precise mix of versions, the harder
it is for anyone to give assurances about how that system may perform.

> In the new system the main/testing packages should be _guaranteed_

NOTHING in Debian is guaranteed. Not even in a stable release is
it guaranteed that all packages will work together. Fairly likely, yes.
Our best effort to achieve as good as we can make it - definitely.
Guarantee? Impossible. Dreamland. Tell you what, you do all the testing
and maybe Debian might refund the cost of the software - oh wait

It all comes down to how many people test any one particular
combination of packages. Many eyes make all bugs shallow; many testers
make for higher probability of packages working together nicely. If
there are fewer eyes on one variant than on another then the more
popular variant will, in all probability, be less buggy - that's just
simple maths. Nothing is guaranteed. There is no warranty.

If you sincerely want the Debian system which has had the most testing
of all possible variants and which Debian can honestly describe as "the
most likely candidate for a system where packages work together as
nicely as it is practical to achieve" you MUST use stable and then keep
that up to date with the stable point releases and security updates.

Building stuff then takes place in chroots, e.g. using pbuilder, based
on whatever suite or mix you require.

Many, many software development companies use this approach for their
own GNU/Linux software development, whether proprietary or not.

> to work together with the most recent core/stable packages. Of course
> they should also work together with core/testing, as they do now.

Who is going to find the many thousands of testers who currently file
bugs against unstable and testing to make a stable release? Any split
would have to have at least as much testing for all possible
permutations, so you have just volunteered to coordinate testing
amongst a set of users as large and as varied as all of the current
Debian userbase for each possible permutation. Well done.

I look forward to seeing all popcon scores treble in the coming
weeks
 
> Making this scheme work would imply more frequent releases for the core
> packages, but I am sure this can be done. I would expect that we would
> get <1000 core packages.

No, it would require huge numbers of testers to use each possible
permutation as their daily use systems across all of the fields in
which Debian is currently used. If not, then the alternative can never
be as good as the current stable release and the whole exercise is
pointless.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpiCI24fa8fC.pgp
Description: PGP signature

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/04/11 07:26, Andrei POPESCU wrote:
> 
> This is one of those recurrent discussions coming up on debian-devel. It 
> is my impression (as a lurker) that most Debian Developers do not want 
> to have second-class packages and it is a feature that all packages in 
> main get (more or less) the same treatment regarding release and 
> security support.

We already have priorities in Debian packages, so this would be
no big difference.

Looking at security: In the suggested scheme it would be
easier to update an insecure package hosted in main. An
explicit backport from testing to stable wouldn't be necessary,
since the packages in main/testing are supposed to be backward
compatible to stable on binary level. Its 1 source package to
update, not 2.


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3qOWwACgkQUTlbRTxpHjfcvwCfd2XAZ0Ca3YPM9aGR4dCAA4co
wOsAn3TT/kY3ZVqq1ztN/8jA1/RCzZRa
=AJSB
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dea396c.3070...@afaics.de

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Neil,

On 06/04/11 12:36, Neil Williams wrote:
> On Sat, 04 Jun 2011 10:12:42 +0200
> Harald Dunkel  wrote:
> 
>> Installing testing for the whole system is no option. The base
>> system (the core packages) should be provided by the most recent
>> release. I don't want to get an unbootable system.
> 
> You are more likely to get a problematic system by MIXING versions than
> you are by sticking just to stable or just to testing. Unbootable is
> fairly unlikely (boot loader bugs aside).
> 

About the package set dependencies:  The core package sets would be
self contained, i.e. they would not depend upon packages outside of
their own core set. The new main/testing repository would be meant
to work with both core/stable and core/testing.

Using some very rough numbers:
Instead of main repositories for stable and testing with 3
packages each we would have core repositories for stable and testing
with 1000 packages each, and a common non-core repository with 29000
packages, to be used together with both core/stable and core/testing.
That would be 6 packages vs 31000 packages.

Of course this means testing and fixing things for some packages.
Compatibility is a quality criteria.

>> In the new system the main/testing packages should be _guaranteed_
> 
> NOTHING in Debian is guaranteed. Not even in a stable release is
> it guaranteed that all packages will work together. Fairly likely, yes.
> Our best effort to achieve as good as we can make it - definitely.
> Guarantee? Impossible. Dreamland. Tell you what, you do all the testing
> and maybe Debian might refund the cost of the software - oh wait
> 

Surely "guaranteed" was the wrong word. Please excuse this mistake.
I didn't mean to upset you.

> If you sincerely want the Debian system which has had the most testing
> of all possible variants and which Debian can honestly describe as "the
> most likely candidate for a system where packages work together as
> nicely as it is practical to achieve" you MUST use stable and then keep
> that up to date with the stable point releases and security updates.
> 

The problem with this is Debian's long release cycle (+2 years, as it
seems). Its difficult to get help from upstream if the source code in
stable is 2 years old. Drbd, libvirt and other virtualization solutions,
third party software, etc. are examples. Not to mention hardware
dependencies. Not to mention that the users would like to use the most
shiny new eye candy system of their dreams, and yet assume to get a
stable XWindow server.

>> Making this scheme work would imply more frequent releases for the core
>> packages, but I am sure this can be done. I would expect that we would
>> get <1000 core packages.
> 
> No, it would require huge numbers of testers to use each possible
> permutation as their daily use systems across all of the fields in
> which Debian is currently used. If not, then the alternative can never
> be as good as the current stable release and the whole exercise is
> pointless.
> 

Looking at today's testing and stable repositories with about 6 binary
packages per platform, and the suggested core/stable, core/testing and
main/testing repositories with about 31000 binary packages per platform,
how many permutations would you expect for each scheme?



Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3qSi4ACgkQUTlbRTxpHjdsfACfblEVtn1XYthjGZrKgKp2F14l
17EAn2cFQxIdZ8yvzgWB6tOSP9PPr0oV
=xrGC
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dea4a2e.5060...@afaics.de

Re: distinguish between "core" and "main"?

[brian m. carlson]

On Sat, Jun 04, 2011 at 05:07:26PM +0200, Harald Dunkel wrote:
> About the package set dependencies:  The core package sets would be
> self contained, i.e. they would not depend upon packages outside of
> their own core set. The new main/testing repository would be meant
> to work with both core/stable and core/testing.

I don't think what you want is likely to happen; nevertheless, the
priorities system does mandate that packages of higher priority not
depend on packages of lower priority.  Depending on your needs, you
could choose packages of important or higher or those of standard or
higher as your core set (this is on sid):

  lakeview ok % aptitude -q search '~prequired|~pimportant' | wc -l
  123
  lakeview ok % aptitude -q search '~prequired|~pimportant|~pstandard' | wc -l
  249

Most of the important or higher packages are very stable and unlikely to
break things at all.  Neither Debian nor I guarantee this, though.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: distinguish between "core" and "main"?

[Neil Williams]

On Sat, 04 Jun 2011 17:07:26 +0200
Harald Dunkel  wrote:

> On 06/04/11 12:36, Neil Williams wrote:
> > On Sat, 04 Jun 2011 10:12:42 +0200
> > Harald Dunkel  wrote:
> > 
> >> Installing testing for the whole system is no option. The base
> >> system (the core packages) should be provided by the most recent
> >> release. I don't want to get an unbootable system.
> > 
> > You are more likely to get a problematic system by MIXING versions than
> > you are by sticking just to stable or just to testing. Unbootable is
> > fairly unlikely (boot loader bugs aside).
> > 
> 
> About the package set dependencies:  The core package sets would be
> self contained, 

They are not, currently. That's a large amount of work and I don't see
any volunteers for that.

> i.e. they would not depend upon packages outside of
> their own core set. The new main/testing repository would be meant
> to work with both core/stable and core/testing.

Tested by whom?

You want quality, that means real people testing real combinations on
real hardware whilst trying to get real work done, not some automated
dependency check. 

Packages only show the full range of bugs when there are enough users
to use each combination of options and methods.

> Using some very rough numbers:
> Instead of main repositories for stable and testing with 3
> packages each we would have core repositories for stable and testing
> with 1000 packages each, and a common non-core repository with 29000
> packages, to be used together with both core/stable and core/testing.
> That would be 6 packages vs 31000 packages.

It's not about package numbers, it is about people - people to test the
combination of packages.
 
> Of course this means testing and fixing things for some packages.
> Compatibility is a quality criteria.

Testing compatibility is the larger problem. Automated tests can only
go so far. Dependencies are one thing, bugs which arise because one
setup is using a version which has already been replaced in testing.

> > If you sincerely want the Debian system which has had the most testing
> > of all possible variants and which Debian can honestly describe as "the
> > most likely candidate for a system where packages work together as
> > nicely as it is practical to achieve" you MUST use stable and then keep
> > that up to date with the stable point releases and security updates.
> 
> The problem with this is Debian's long release cycle (+2 years, as it
> seems). Its difficult to get help from upstream if the source code in

Then use chroots, as explained in my first message but which you appear
to have ignored.

I do this every single working day. I run a number of boxes using
stable - each has pbuilder support for sid and most have pdebuild-cross
support for cross-building for armel based on stable or unstable.

The long release cycle arises from the very thing you appear to cherish
- the quality and stability of the stable release. It takes time and
people to generate quality. That's the entire problem - there are not
enough people to do that testing twice over.

Pushing an artificial division into that where only a tiny fraction of
users actually use that particular combination of packages undermines
the entire objective of using stable in the first place. Some people
choose to use mixed systems, there are not enough of those to assure
quality of such combinations.

That is why others here have recommended using testing in the first
place if you want to genuinely build packages on testing due to the
versions of the dependencies you need.

> >> Making this scheme work would imply more frequent releases for the core
> >> packages, but I am sure this can be done. I would expect that we would
> >> get <1000 core packages.
> > 
> > No, it would require huge numbers of testers to use each possible
> > permutation as their daily use systems across all of the fields in
> > which Debian is currently used. If not, then the alternative can never
> > be as good as the current stable release and the whole exercise is
> > pointless.
> 
> Looking at today's testing and stable repositories with about 6 binary
> packages per platform, and the suggested core/stable, core/testing and
> main/testing repositories with about 31000 binary packages per platform,
> how many permutations would you expect for each scheme?

Testers = people. There are as many permutations as there are testers -
or if you really want the figures, work out how many possible
permutations there are for installing 1,500 packages out of a total
selection of 31,000. Then find people to test each permutation on a
daily, regular usage basis - ensuring that each person fully tests
EVERY application in their particular set.

Completely unrealistic because we already have that for the current
single permutation - it's what gets into stable.

Even a single permutation DOUBLES the number of people running Debian.
I'm not against that, I just don't think it is realistic.

-- 


Neil Williams
=

Re: distinguish between "core" and "main"?

[Tshepang Lekhonkhobe]

On Sat, 2011-06-04 at 08:54 +0200, Harald Dunkel wrote:
> On 06/04/11 07:56, Paul Wise wrote:
> > Sounds like you are looking for backports.debian.org?
> > 
> 
> Backports for Squeeze contains just about 400 package,
> AFIACS.

Would this be good enough for you if there were thousands of packages
instead?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1307226818.12430.24.camel@debian

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Neil,

On 06/04/11 19:01, Neil Williams wrote:
> 
> Testing compatibility is the larger problem. Automated tests can only
> go so far. Dependencies are one thing, bugs which arise because one
> setup is using a version which has already been replaced in testing.
> 

As a consumer I would like to get a system that keeps up to date
(as today's testing does), but with a stable core package set. I
would like to install the most recent stable core system, and use
testing for everything else.

All these APIs and dynamic libraries are meant to provide backward
compatibility. We also have versioned package names to work around
compatibility problems. But we don't really rely on this, except for
updates within testing or unstable.

>>> If you sincerely want the Debian system which has had the most testing
>>> of all possible variants and which Debian can honestly describe as "the
>>> most likely candidate for a system where packages work together as
>>> nicely as it is practical to achieve" you MUST use stable and then keep
>>> that up to date with the stable point releases and security updates.
>>
>> The problem with this is Debian's long release cycle (+2 years, as it
>> seems). Its difficult to get help from upstream if the source code in
> 
> Then use chroots, as explained in my first message but which you appear
> to have ignored.
> 

Probably I had misunderstood your "Building stuff then takes place in
chroots, e.g. using pbuilder". I had associated pbuilder with "building
packages".

> I do this every single working day. I run a number of boxes using
> stable - each has pbuilder support for sid and most have pdebuild-cross
> support for cross-building for armel based on stable or unstable.
> 

Instead of pbuilder I am using virtual machines (kvm & vserver)
with testing today. Their biggest advantages (as with pbuilder I
would guess) are hiding the real hardware and keeping things separate
from each other.

The downside is that everything gets more complex, but not necessarily
more stable. You've got even more systems to run and more packages to
install, not to mention that updates of the virtualization server
are more difficult to do.

My virtualization servers themselves were running testing, too, but
since Squeeze has been released testing is changing rapidly. Currently
I cannot rely upon testing for server installations.

> The long release cycle arises from the very thing you appear to cherish
> - the quality and stability of the stable release. It takes time and
> people to generate quality. That's the entire problem - there are not
> enough people to do that testing twice over.
> 
> 
> Testers = people. There are as many permutations as there are testers -
> or if you really want the figures, work out how many possible
> permutations there are for installing 1,500 packages out of a total
> selection of 31,000. Then find people to test each permutation on a
> daily, regular usage basis - ensuring that each person fully tests
> EVERY application in their particular set.
> 

Understood. If you reduce the number of packages to be released by
focusing on a core package set with 1000 or 1500 packages instead
of +3, then your can do more rapid releases because there are
fewer packages to wait for matching the release criteria.

Of course this doesn't make the +29000 packages outside of the
proposed core repository go away. But I think we already agreed to
use testing for installations of "non-core" packages.

I would guess most testing happens in unstable, before a package
gets promoted to testing, anyway.


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3rIiIACgkQUTlbRTxpHjfh3QCfXMKW16yza5S9sG4t7vZdNMgx
ZsYAni1DtpWYxf9ubYmwCATbGXhS7LAW
=lBo9
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4deb222f.8020...@afaics.de

Re: distinguish between "core" and "main"?

[Tshepang Lekhonkhobe]

On Sun, 2011-06-05 at 08:29 +0200, Harald Dunkel wrote:
> Hi Neil,
> 
> On 06/04/11 19:01, Neil Williams wrote:
> > 
> > Testing compatibility is the larger problem. Automated tests can only
> > go so far. Dependencies are one thing, bugs which arise because one
> > setup is using a version which has already been replaced in testing.
> > 
> 
> As a consumer I would like to get a system that keeps up to date
> (as today's testing does), but with a stable core package set. I
> would like to install the most recent stable core system, and use
> testing for everything else.
> 
> All these APIs and dynamic libraries are meant to provide backward
> compatibility. We also have versioned package names to work around
> compatibility problems. But we don't really rely on this, except for
> updates within testing or unstable.
> 
> >>> If you sincerely want the Debian system which has had the most testing
> >>> of all possible variants and which Debian can honestly describe as "the
> >>> most likely candidate for a system where packages work together as
> >>> nicely as it is practical to achieve" you MUST use stable and then keep
> >>> that up to date with the stable point releases and security updates.
> >>
> >> The problem with this is Debian's long release cycle (+2 years, as it
> >> seems). Its difficult to get help from upstream if the source code in
> > 
> > Then use chroots, as explained in my first message but which you appear
> > to have ignored.
> > 
> 
> Probably I had misunderstood your "Building stuff then takes place in
> chroots, e.g. using pbuilder". I had associated pbuilder with "building
> packages".
> 
> > I do this every single working day. I run a number of boxes using
> > stable - each has pbuilder support for sid and most have pdebuild-cross
> > support for cross-building for armel based on stable or unstable.
> > 
> 
> Instead of pbuilder I am using virtual machines (kvm & vserver)
> with testing today. Their biggest advantages (as with pbuilder I
> would guess) are hiding the real hardware and keeping things separate
> from each other.
> 
> The downside is that everything gets more complex, but not necessarily
> more stable. You've got even more systems to run and more packages to
> install, not to mention that updates of the virtualization server
> are more difficult to do.
> 
> My virtualization servers themselves were running testing, too, but
> since Squeeze has been released testing is changing rapidly. Currently
> I cannot rely upon testing for server installations.
> 
> > The long release cycle arises from the very thing you appear to cherish
> > - the quality and stability of the stable release. It takes time and
> > people to generate quality. That's the entire problem - there are not
> > enough people to do that testing twice over.
> > 
> > 
> > Testers = people. There are as many permutations as there are testers -
> > or if you really want the figures, work out how many possible
> > permutations there are for installing 1,500 packages out of a total
> > selection of 31,000. Then find people to test each permutation on a
> > daily, regular usage basis - ensuring that each person fully tests
> > EVERY application in their particular set.
> > 
> 
> Understood. If you reduce the number of packages to be released by
> focusing on a core package set with 1000 or 1500 packages instead
> of +3, then your can do more rapid releases because there are
> fewer packages to wait for matching the release criteria.

By rapid releases, are you referring to core/stable or main/testing? How
rapid? Do you mean people would now do system upgrades in less than 2-3
years (life of a Debian release)?

> Of course this doesn't make the +29000 packages outside of the
> proposed core repository go away. But I think we already agreed to
> use testing for installations of "non-core" packages.

But it makes them second-class. Also, backports is supposed to fix this
anyway. All needed there is volunteers willing to do the work. Why would
you want a different scheme?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1307272657.16407.10.camel@debian

Re: distinguish between "core" and "main"?

[Kyle Willmon]

On Sat, Jun 04, 2011 at 05:07:26PM +0200, Harald Dunkel wrote:
> About the package set dependencies:  The core package sets would be
> self contained, i.e. they would not depend upon packages outside of
> their own core set. The new main/testing repository would be meant
> to work with both core/stable and core/testing.
> 
> Using some very rough numbers:
> Instead of main repositories for stable and testing with 3
> packages each we would have core repositories for stable and testing
> with 1000 packages each, and a common non-core repository with 29000
> packages, to be used together with both core/stable and core/testing.
> That would be 6 packages vs 31000 packages.

Based on these numbers, your suggestion removes stable/main and uses
testing/main for all "stable" systems. This introduces the idea that
packages in a system that we consider to be "stable" have only been
tested for 10 days (the time it takes for a low priority package to
migrate from unstable to testing).

The idea further says nothing about oldstable, which is a supported
Debian release. It takes the benefit of installing a system and knowing
that it will be supported for the next 4yrs away completely and this is
something than many Debian users cherish.

> Drbd, libvirt and other virtualization solutions,
> third party software, etc. are examples.

The idea of second-class packages means specializing what Debian is used
for. You may consider it alright that your virtualization software has
only been tested for 10 days. Other people would rather have the
virtualization software that has been tested for much longer and won't
crash their production virtual machines. So, does that virtualization
software belong in core or main? We've already seen what you think, but
I'd be willing to bet many Debian users would disagree.

Debian is the universal operating system. If you want to specialize what
Debian does, please consider starting a Debian derivative. Assuming you
are not alone in your ideas, you may have some future user base waiting
for you.

Thanks
--
Kyle Willmon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110605153155.gb11...@mail.tuxags.com

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/05/11 13:17, Tshepang Lekhonkhobe wrote:
> On Sun, 2011-06-05 at 08:29 +0200, Harald Dunkel wrote:
>>
>> Understood. If you reduce the number of packages to be released by
>> focusing on a core package set with 1000 or 1500 packages instead
>> of +3, then your can do more rapid releases because there are
>> fewer packages to wait for matching the release criteria.
> 
> By rapid releases, are you referring to core/stable or main/testing? How
> rapid? Do you mean people would now do system upgrades in less than 2-3
> years (life of a Debian release)?
> 

Only core/stable should be released. The "rest" comes from
main/testing.

I cannot speak for others, but I don't wait 3 years. I do
regular updates/upgrades to include the most recent security
and bug fixes. We've scheduled regular maintenance weekends
every 3 months for this. Important updates are installed
immediately.

>> Of course this doesn't make the +29000 packages outside of the
>> proposed core repository go away. But I think we already agreed to
>> use testing for installations of "non-core" packages.
> 
> But it makes them second-class.

They are surely not second-class, they are just not within core/stable.
Debian already classifies packages in different priorities, to
be used today when package updates are pushed into testing, for
example. I just cannot use these priorities in sources.list, _and_ I
cannot rely upon the packages in today's testing to work with the
core packages in stable

> Also, backports is supposed to fix this
> anyway. All needed there is volunteers willing to do the work. Why would
> you want a different scheme?
> 

Because backports is not supported as good as the current
testing repo. Why have a 3rd repository next to stable and
testing with a similar package set, instead of keeping an
eye upon compatibility right from the start?

I understand that splitting main into core/stable and
main/testing would be a deep cut. Surely I do not expect it
to happen within the next few weeks or months. Just think
about it.


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3rqIYACgkQUTlbRTxpHjcGBQCeLcGloib4F3WXlHz/GeHCazyd
ja4An2lzCyVvGrQUyVLjWvXipyZyY0cO
=Bz2S
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4deba886.5000...@afaics.de

Re: distinguish between "core" and "main"?

[Bernhard R. Link]

* Harald Dunkel  [110605 18:02]:
> Only core/stable should be released. The "rest" comes from
> main/testing.
>
> I cannot speak for others, but I don't wait 3 years. I do
> regular updates/upgrades to include the most recent security
> and bug fixes. We've scheduled regular maintenance weekends
> every 3 months for this. Important updates are installed
> immediately.

And have to explain every user every 3 months that their browser is
now looking slightly different and their window manager is behaving
differently and all the other programs no longer do what they want?

There is simply no way to test stuff and get enough bugs out of the
installation in only 3 months. Having some software newer is possible
if one is enough into those projects to understand what exactly is
changing, but everything else is core, and as every admin is interested
about different things, all of Debian has to be core to be useful.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110605160830.ga4...@pcpool00.mathematik.uni-freiburg.de

Re: distinguish between "core" and "main"?

[Philip Hands]

On Sun, 05 Jun 2011 08:29:03 +0200, Harald Dunkel  wrote:
...
> My virtualization servers themselves were running testing, too, but
> since Squeeze has been released testing is changing rapidly. Currently
> I cannot rely upon testing for server installations.

So use stable + backports for now, and once testing has settled down a
bit, and you've accumulated enough backports to make that a pain, switch
to testing.  That cycle of usage is part of what ensures that the next
release gets enough testing.

Your pipe-dream of an effortless, stable, and up to date system is just
that -- pick any two.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpo3kyWv0zWZ.pgp
Description: PGP signature

Re: distinguish between "core" and "main"?

[Timo Juhani Lindfors]

Hi,

Philip Hands  writes:
> On Sun, 05 Jun 2011 08:29:03 +0200, Harald Dunkel  wrote:
> Your pipe-dream of an effortless, stable, and up to date system is just
> that -- pick any two.

I personally prefer stable system with unstable chroot. This gives me
best of both worlds. I can use both stable and unstable version of the
same package if I want. I can still report bugs to debian since the
packages are unmodified.

With suitable bind mounts even freedesktop.org applications work quite
ok.

My current recipe is

1) sudo apt-get install debootstrap schroot
2) sudo mkdir /sid
3) sudo debootstrap sid /sid http://ftp.fi.debian.org/debian
4) Add the following to /etc/schroot/schroot.conf

[sid]
description=Debian sid (unstable)
location=/sid
aliases=unstable,default
users=user1,user2

where user1 and user2 are users that are allowed to use the chroot
(change them!).

5) Add the following to /etc/fstab

/home /sid/homenone bind 0 0
/dev  /sid/dev none bind 0 0
/dev/pts  /sid/dev/pts none bind 0 0
/dev/shm  /sid/dev/shm none bind 0 0
/proc /sid/procnone bind 0 0
/sys  /sid/sys none bind 0 0
/tmp  /sid/tmp none bind 0 0
/var/run/dbus /sid/var/run/dbusnone bind 0 0

5.1) sudo mkdir /sid/var/run/dbus

6) sudo mount -a

7) sudo cp /etc/sudoers /etc/hosts /etc/hostname /etc/passwd /etc/shadow
/etc/group /sid/etc

8) Create /usr/local/bin/sid with the following lines

#!/bin/sh
schroot -c sid -p -q -- "$@"

8.1) sudo chmod a+x /usr/local/bin/sid

9) Create /sid/usr/sbin/policy-rc.d to prevent daemons from starting
accidentally inside the chroot with the following lines

#!/bin/sh
logger "sid $0 invoked with $@"
exit 101

9.1) sudo chmod a+x /sid/usr/sbin/policy-rc.d

10) (just an example) sudo sid apt-get install openoffice.org

11) (just an example) sid openoffice.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84fwno6x9w@sauna.l.org

Re: distinguish between "core" and "main"?

[Tshepang Lekhonkhobe]

On Sun, 2011-06-05 at 18:02 +0200, Harald Dunkel wrote:
> I cannot speak for others, but I don't wait 3 years. I do
> regular updates/upgrades to include the most recent security
> and bug fixes. We've scheduled regular maintenance weekends
> every 3 months for this. Important updates are installed
> immediately.

NOTE: I specifically chose the words "system upgrade", so as to be clear
I'm not including security updates and stability fixes.

So, you want Debian to change its release management to suit you, while
neglecting what is likely its largest userbase. I'm here referring to
users who don't want to do system upgrades every 3 months.

> >> Of course this doesn't make the +29000 packages outside of the
> >> proposed core repository go away. But I think we already agreed to
> >> use testing for installations of "non-core" packages.
> > 
> > But it makes them second-class.
> 
> They are surely not second-class, they are just not within core/stable.
> Debian already classifies packages in different priorities, to
> be used today when package updates are pushed into testing, for
> example. I just cannot use these priorities in sources.list, _and_ I
> cannot rely upon the packages in today's testing to work with the
> core packages in stable

Hmmm...

> > Also, backports is supposed to fix this
> > anyway. All needed there is volunteers willing to do the work. Why would
> > you want a different scheme?
> > 
> 
> Because backports is not supported as good as the current
> testing repo. Why have a 3rd repository next to stable and
> testing with a similar package set, instead of keeping an
> eye upon compatibility right from the start?

What do you mean by "backports is not supported as good as the current
testing repo"? Do you mean the packages there are too small in number?

Talking about your proposed scheme, let's assume that the GNU toolchain
would be part of core/stable. Would you agree that keeping it compatible
with the rest of the system means building the rest of the system with
it? That means keeping it hostage and not updating it for a set period
of time. Now what backports does is that you'll use build tools in
stable to build newer software than is available in stable, to avoid
upgrading a "certified stable" base. And this is a compromise between
stability and freshness. If I'm accurate thus far, it means you are
asking for making a backports system the main way of doing Debian, and
neglecting about everyone else. I'm saying this because we can't have a
main/testing system that's built both by a core/stable version of this
toolchain and a main/testing version. Am I missing anything (sorry if
I'm making you repeat yourself)?




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1307296843.19746.31.camel@debian

Re: distinguish between "core" and "main"?

[Adam D. Barratt]

On Sun, 05 Jun 2011 18:02:14 +0200, Harald Dunkel wrote:

Debian already classifies packages in different priorities, to
be used today when package updates are pushed into testing, for
example.


You appear to have confused package priority and upload urgency.  
Testing migration is affected by the latter, not the former.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/40730830c631d8131964ae5792db3...@adsl.funky-badger.org

Re: distinguish between "core" and "main"?

[Josselin Mouette]

Le dimanche 05 juin 2011 à 18:02 +0200, Harald Dunkel a écrit : 
> I understand that splitting main into core/stable and
> main/testing would be a deep cut. Surely I do not expect it
> to happen within the next few weeks or months. Just think
> about it.

What you do not understand is how presumptuous and condescending it is
to come with vague ideas of new release schemes without any experience
of the problems behind, and tell people to “think about it”.

If the current release process doesn’t suit your needs, just tell us in
what ways. You’re not the first one, and a lot of us already “think
about it”. We might even be close to provide a solution to an entire
class of problems with the rolling release concept.

As you might have noticed in the discussion, the broad consensus among
developers is that splitting the distribution is not an option. Apart
from the core toolchain (and still, you will find some loose adherence
with it in various pieces of software), it is not possible to release a
part of the distribution separately. The kernel is tied to desktops,
desktops are tied to server components, server components are tied to
web frameworks, web applications are tied to interpreters and
interpreters are tied to desktop applications… there’s no end to it.
Those who split the distribution, like Ubuntu, only do it for levels of
support, not for release schedules.

Another broad consensus is that stopping to provide stable releases is
not an option either. If you want to propose an evolution in the release
process, you have to wonder how it affects stable releases too.

These are two good reasons why your idea, in its current state, is not
even remotely applicable. Now if you want to be listened to, you need to
talk with people familiar with these problems, come up with new ideas
and explain what problems they solve. It’s better than asking people to
“think about it”.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


signature.asc
Description: This is a digitally signed message part

Re: distinguish between "core" and "main"?

[Paul Wise]

On Sat, Jun 4, 2011 at 2:54 PM, Harald Dunkel wrote:
> On 06/04/11 07:56, Paul Wise wrote:
>> Sounds like you are looking for backports.debian.org?
>
> Backports for Squeeze contains just about 400 package,

Hmm, I'm getting the impression that what you want is a
squeeze-backports-auto suite that contains packages from testing like
stable-backports but fully automatically built and with no QA by
maintainers to ensure it builds/works on stable?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTikAGHn=hgb_6dcn8fjck6sunh+...@mail.gmail.com

Re: distinguish between "core" and "main"?

[Russ Allbery]

Paul Wise  writes:
> On Sat, Jun 4, 2011 at 2:54 PM, Harald Dunkel wrote:
>> On 06/04/11 07:56, Paul Wise wrote:

>>> Sounds like you are looking for backports.debian.org?

>> Backports for Squeeze contains just about 400 package,

> Hmm, I'm getting the impression that what you want is a
> squeeze-backports-auto suite that contains packages from testing like
> stable-backports but fully automatically built and with no QA by
> maintainers to ensure it builds/works on stable?

I still think this whole conversation is based on a false premise.  I
think the original request originated from a belief that there is some
separable part of "core" Debian which could be held stable, and that
keeping that portion stable while using testing packages for everything
else would improve the stability of the system.

I don't think either of those assumptions are true.  There is a *lot* of
entanglement between new packages and new libraries that goes deep into
what one would call "core," and the few things that are so stable that
they wouldn't require upgrading to support testing packages also hardly
change from release to release and are really unlikely to break in
testing.

In other words, yes, you can use stable tar on a system otherwise using
testing, but the chances of the testing version of tar being unstable are
very low.  I can see wanting to keep using a stable version of GTK+, but
then you're not going to be able to upgrade GNOME packages, which probably
includes some of the stuff one particularly wanted to upgrade.

In other words, just use testing.  It will be just as stable as this
constructed distribution, if not more so.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aadvk0px@windlord.stanford.edu

Re: distinguish between "core" and "main"?

[Simon McVittie]

On Sun, 05 Jun 2011 at 08:29:03 +0200, Harald Dunkel wrote:
> All these APIs and dynamic libraries are meant to provide backward
> compatibility.

You're asking for forward compatibility, though: making applications in
testing/main limit themselves to only doing things which already worked in
stable/core, and avoiding relying on new features (or new bug fixes) from
testing/core.

In other words, we'd be artificially imposing the platform problem
. It's hard enough to avoid that problem
*already*, we don't want more of it! Core libraries (and toolchains, and the
kernel) gain new features for a reason - to support better new versions of
applications.

(Backward compatibility is when an outdated application still works on
newer libraries/kernel/other underlying components, and in general we already
have that.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110606083622.ga28...@reptile.pseudorandom.co.uk

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/06/11 07:06, Russ Allbery wrote:
> 
> I still think this whole conversation is based on a false premise.  I
> think the original request originated from a belief that there is some
> separable part of "core" Debian which could be held stable, and that
> keeping that portion stable while using testing packages for everything
> else would improve the stability of the system.
> 

Not exactly. I would like to get a stable build and runtime environment
for the packages in main/testing.

That doesn't mean that there are no newer versions of the same tools
installed in parallel, as it is done today with gcc vs gcc-4.6, their
runtime environments, and a lot of other packages.

I would like to suggest to keep these core packages in a seperate
repository, though.

> I don't think either of those assumptions are true.  There is a *lot* of
> entanglement between new packages and new libraries that goes deep into
> what one would call "core," and the few things that are so stable that
> they wouldn't require upgrading to support testing packages also hardly
> change from release to release and are really unlikely to break in
> testing.
> 

The core should be self-contained. I would guess you doubt that this
is possible?

Surely it would be difficult to know where to cut the line.


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3tVvwACgkQUTlbRTxpHjem2QCfbU1V7Bbpcgpq9Gs4B8fZ6kcF
QjkAnijWsY1yM6pYeFrPjt2X2/40g4OP
=x0v5
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ded5701.7020...@afaics.de

Re: distinguish between "core" and "main"?

[Russ Allbery]

Harald Dunkel  writes:
> On 06/06/11 07:06, Russ Allbery wrote:

>> I still think this whole conversation is based on a false premise.  I
>> think the original request originated from a belief that there is some
>> separable part of "core" Debian which could be held stable, and that
>> keeping that portion stable while using testing packages for everything
>> else would improve the stability of the system.

> Not exactly. I would like to get a stable build and runtime environment
> for the packages in main/testing.

Yes, that's what I'm saying doesn't actually exist.  There isn't, in
Debian, such a thing as a "build and runtime environment" that's separate
from the packages.  The packages *are* the build and runtime environment.

It's kind of like asking for walls separate from your house.

> I would like to suggest to keep these core packages in a seperate
> repository, though.

> The core should be self-contained. I would guess you doubt that this is
> possible?

More just irrelevant.  It doesn't matter whether the core is
self-contained for what you're proposing.  The problem is that the
packages that you want to run depend on newer versions of the packages
that you consider core, for basically any useful definition of "core."

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r576y39x@windlord.stanford.edu

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/07/11 00:59, Russ Allbery wrote:
> Harald Dunkel  writes:
> 
>> Not exactly. I would like to get a stable build and runtime environment
>> for the packages in main/testing.
> 
> Yes, that's what I'm saying doesn't actually exist.  There isn't, in
> Debian, such a thing as a "build and runtime environment" that's separate
> from the packages.  The packages *are* the build and runtime environment.
> 

There already is: Debian is shipping a "stable" gcc/g++ in parallel
to an up-to-date version, for example. My suggestion is to extend
this scheme, and to keep these packages separate from the current
testing.

> It's kind of like asking for walls separate from your house.
> 

Its more like keeping the basement stable, while building new
walls on top of it.

> 
> More just irrelevant.  It doesn't matter whether the core is
> self-contained for what you're proposing.  The problem is that the
> packages that you want to run depend on newer versions of the packages
> that you consider core, for basically any useful definition of "core."
> 

I do not see that. All packages were available at build time in
the right version. Where should this broken dependency come from,
unless you are ignoring dependencies on promoting packages from
unstable to testing to stable?


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3xqpEACgkQUTlbRTxpHjdA7wCfbEt+vz9mO8INYg8vNCtFiOJk
JNQAn2m1+g53dN0zno9BtSnq5opJHLL+
=nIMt
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4df1aa96.8090...@afaics.de

Re: distinguish between "core" and "main"?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/10/11 07:24, Harald Dunkel wrote:
> 
> I do not see that. All packages were available at build time in
> the right version. Where should this broken dependency come from,
> unless you are ignoring dependencies on promoting packages from
> unstable to testing to stable?
> 

More precisely:

... promoting packages from unstable to main/testing or core/stable?


Regards

Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3xq8YACgkQUTlbRTxpHjercQCfeQrKb2nA6NgBXfQtjcBpDOdf
BbIAniKJEEHsQSPf9awrjBLt+Fa/eaDD
=2Hbr
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4df1abc6.7020...@afaics.de

Re: distinguish between "core" and "main"?

[Philip Hands]

Hi Ha

On Fri, 10 Jun 2011 07:24:38 +0200, Harald Dunkel  wrote:
...
> > It's kind of like asking for walls separate from your house.
> > 
> 
> Its more like keeping the basement stable, while building new
> walls on top of it.

Yes, it's exactly like that -- and you're just like the sort of DIY
builder who confidently goes ahead and moves the load bearing walls in
his house, despite the fact that various professional builders have
all quoted rather a lot of money for the job -- but that's because they
know that you need to make sure that the basement is not going to
collapse, and it's not just a case of upgrading the basement layout in
one step, because of course you need to support the old load bearing
walls during the procedure, so you end up with a basement full of RSJs
and props, which means that it's not so great as a basement any more.

You on the other hand get to come home to a big hole in the ground.

Can we stop this nonsense now?

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpU3DoWNCFq6.pgp
Description: PGP signature