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
06-04-2011, 05:45 AM
Harald Dunkel
distinguish between "core" and "main"?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi folks,
Having 30000+ 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/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE9C680.70205@afaics.de">http://lists.debian.org/4DE9C680.70205@afaics.de
06-04-2011, 05:56 AM
Paul Wise
distinguish between "core" and "main"?
Sounds like you are looking for backports.debian.org?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTinAFUyM1LUDT=szcAwXsxx403gOjw@mail.gmail.com ">http://lists.debian.org/BANLkTinAFUyM1LUDT=szcAwXsxx403gOjw@mail.gmail.com
06-04-2011, 06:15 AM
"Thijs Kinkhorst"
distinguish between "core" and "main"?
On Sat, June 4, 2011 07:45, Harald Dunkel wrote:
> Having 30000+ 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: e2d706e63e854b3c34f2d5badfc024d4.squirrel@wm.kinkh orst.nl">http://lists.debian.org/e2d706e63e854b3c34f2d5badfc024d4.squirrel@wm.kinkh orst.nl
06-04-2011, 06:54 AM
Harald Dunkel
distinguish between "core" and "main"?
-----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/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE9D692.3000403@afaics.de">http://lists.debian.org/4DE9D692.3000403@afaics.de
06-04-2011, 07:05 AM
Paul Wise
distinguish between "core" and "main"?
On Sat, Jun 4, 2011 at 2:54 PM, Harald Dunkel <harri@afaics.de> 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.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTiniAgW+sKsjv-GaP=kSXHUtLii_wg@mail.gmail.com">http://lists.debian.org/BANLkTiniAgW+sKsjv-GaP=kSXHUtLii_wg@mail.gmail.com
06-04-2011, 07:06 AM
Russ Allbery
distinguish between "core" and "main"?
Harald Dunkel <harri@afaics.de> 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.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hb86ulc6.fsf@windlord.stanford.edu">http://lists.debian.org/87hb86ulc6.fsf@windlord.stanford.edu
06-04-2011, 08:12 AM
Harald Dunkel
distinguish between "core" and "main"?
-----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/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DE9E8FA.3060201@afaics.de">http://lists.debian.org/4DE9E8FA.3060201@afaics.de
06-04-2011, 10:19 AM
Neil Williams
distinguish between "core" and "main"?
On Sat, 04 Jun 2011 07:45:36 +0200
Harald Dunkel <harri@afaics.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folks,
>
> Having 30000+ 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/
06-04-2011, 10:36 AM
Neil Williams
distinguish between "core" and "main"?
On Sat, 04 Jun 2011 10:12:42 +0200
Harald Dunkel <harri@afaics.de> 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/